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CHAPTER  1 
INTRODUCTION 


The  Ada  implementation  described  above  was  tested  according  to  the  Ada  Validation  Procedures 
[Pro90]  against  the  Ada  Standard  [Ada83]  using  the  current  Ada  Compiler  Validation  Capability 
(ACVC).  This  Validation  Summary  Report  (VSR)  gives  an  account  of  the  testing  of  tl^  Ada 
implementation.  For  any  technical  terms  used  in  t^  report,  the  reader  is  referred  to  [Pro90].  A 
detailed  description  of  the  ACVC  may  be  found  in  the  current  ACVC  User’s  Guide  {UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada  CertiScation  Body  may  make 
full  and  free  public  disclosure  of  this  report.  In  the  United  States,  this  is  provided  in  accordance  with 
the  "Freedom  of  Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply  only  to  the 
computers,  operating  systems,  and  compiler  versions  identified  in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not  represent  or  warrant  that 
all  statements  set  forth  in  this  report  are  accurate  and  complete,  or  that  the  subject  implementation 
has  no  nonconformities  to  the  Ada  Standard  other  than  those  presented.  Copies  of  this  report  are 
available  to  the  public  from  the  AVF  which  performed  this  validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 

Questions  regarding  this  report  or  the  validation  test  results  should  be  directed  to  the  AVF  which 
performed  this  validation  or  to: 

Ada  Validation  Organization 

Computer  and  Software  Engineering  Division 

Institute  for  Defense  Analyses 

1801  North  Beauregard  Street 

Alexandria  VA  22311-1772 

1.2  REFERENCES 

[Ada83]  Reference  Manual  for  the  Ada  Prowamming  Language. 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

(Pro90]  Ada  Compiler  Validation  Procedures. 

Version  2.1,  Ada  Joint  Program  Office,  August  1990. 
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[UG89]  Ada  Compiler  Validation  Capability  User’s  Guide. 

21  June  1989. 


1.3  ACVC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC  contains  a 
collection  of  test  programs  structured  into  six  test  classes:  A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a 
test  name  identifies  the  class  to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link  time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a  PASSED,  FAILED,  or 
NOT  APPLICABLE  message  indicating  the  result  when  they  are  executed.  Three  Ada  library  units, 
the  packages  REPORT  and  SPPRT13,  and  the  procedure  CHECK_FILE  are  used  for  this  purpose. 
The  package  REPORT  also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test  objective.  The  package 
SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the  Ada  Standard.  The  proc^ure  CHECK_FILE 
is  used  to  check  the  contents  of  text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the 
Ada  Standard.  The  operation  of  REPORT  and  CHECK_FILE  is  checked  by  a  set  of  executable  tests. 
If  these  units  are  not  operating  correctly,  validation  testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class  B  tests  are  not  executable. 
Each  test  in  this  class  is  compiled  and  the  resulting  compilation  listing  is  examined  to  verify  that  all 
violations  of  the  Ada  Standard  are  detected.  Some  of  the  class  B  tests  contain  legal  Ada  code  which 
must  not  be  flagged  illegal  by  the  compiler.  This  behaviour  is  also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation  of  the  Ada  Standard 
involving  multiple,  separately  compiled  units.  Errors  are  expected  at  link  time,  and  execution  is 
attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by  implementation-specific 
values  "  for  example,  the  largest  integer.  A  list  of  the  values  used  for  this  implementation  is  provided 
in  Appendix  A.  In  addition  to  these  anticipated  test  modifications,  additional  changes  may  be  required 
to  remove  unforeseen  conflicts  between  the  tests  and  implementation-dependent  characteristics.  The 
modifications  required  for  this  implementation  are  described  in  section  2.3. 

For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the  AVF.  This  customization 
consists  of  making  the  modifications  described  in  the  preening  paragraph,  removing  withdrawn  tests 
(see  section  2.1),  and  possibly  removing  some  inapplicable  tests  (see  section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of  the  customized  test  suite 
according  to  the  Ada  Standard. 
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1.4  DEFINITION  OF  TERMS 

Ada  Compiler  The  software  and  any  needed  hardware  that  have  to  be  added  to  a  given 

host  and  target  computer  system  to  allow  transformation  of  Ada 
programs  into  executable  form  and  execution  thereof. 

Ada  Compiler  The  means  for  testing  compliance  of  Ada  implementations,  consisting  of 

Validation  Capability  the  test  suite,  the  support  progrants,  the  ACVC  user’s  guide  and  the 

(ACVC)  template  for  the  validation  summary  report. 

Ada  Implementation  An  Ada  compQer  with  its  host  computer  system  and  its  target  computer 

system. 

Ada  Joint  Program  The  part  of  the  certification  body  which  provides  policy  and  guidance  for 

Office  (AJPO)  the  Ada  certification  system.  _  . 

Ada  Validation  Facility  The  part  of  the  certification  body  which  carries  out  the  procedures 

(AVF)  required  to  establish  the  compliance  of  an  Ada  implementation. 

Ada  Validation  The  part  of  the  certification  body  that  provides  technical  guidance  for 

Organization  (AVO)  operations  of  the  Ada  certification  system. 

Compliance  of  an  Ada  The  ability  of  the  implementation  to  pass  an  ACVC  version. 

Implementation 

Computer  System  A  functional  unit,  consisting  of  one  or  more  computers  and  associated 

software,  that  uses  common  storage  for  ail  or  part  of  a  program  and  also 
for  ail  or  part  of  the  data  necessary  for  the  execution  of  the  program; 
executes  user-written  or  user-designated  programs;  performs  user- 
designated  date  manipulation,  including  arithmetic  operations  and  logic 
operations;  and  that  can  execute  programs  that  modify  themselves  during 
execution.  A  computer  system  may  be  a  stand-alone  unit  or  may  consist 
of  several  inter-cormected  units. 

Conformity  Fulfilment  of  a  product,  process  or  service  of  all  requirements  specified. 

Customer  An  individual  or  corporate  entity  who  enters  into  an  agreement  with  an 

AVF  which  specifies  the  terms  and  conditions  for  AVF  services  (of  any 
kind)  to  be  performed. 

Declaration  of  A  formal  statement  from  a  customer  assuring  that  conformity  is  realized 

Conformance  or  attainable  on  the  Ada  implementation  for  which  validation  status  is 

realized. 

Host  Computer  System  A  computer  system  where  Ada  source  programs  are  transformed  into 

executable  form. 
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Inapplicable  test 

ISO 

LRM 

Operating  System 

Target  Computer 
System 

Validated  Ada  Compiler 

Validated  Ada 
Implementation 

Validation 

Withdrawn  test 


Validation  SuMary  Report 


A  test  that  contains  one  or  more  test  objectives  found  to  be  irrelevant  for 
the  given  Ada  implementation. 

International  Organization  for  Standardization. 

The  Ada  standard,  or  Language  Reference  Manual,  published  as 
ANSI/MIL-STD-1815A-1983  AND  ISO  8652-1987.  Citations  from  the 
LRM  take  the  form  "<section>.<subsection>:<paragraph>." 

Software  that  controls  the  execution  of  programs  and  that  provides 
services  such  as  resource  allocation,  scheduling,  input/output  control  and 
data  management.  Usually,  operating  systems  are  predominantly 
software,  but  partial  or  complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs  are 
execut^. 

The  compiler  of  a  validated  Ada  implementation. 

An  Ada  implementation  that  has  been  validated  successfully  either  by 
AVF  testing  or  by  registration  [Pro90]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to  the  Ada 
programming  language  and  of  issuing  a  certifrcate  for  this 
implementation. 

A  test  found  to  be  incorrect  and  not  used  m  conformity  testing.  A  test 
may  be  incorrect  because  it  has  an  invalid  test  objective,  fails  to  meet  its 
test  objective,  or  contains  erroneous  or  illegal  use  of  the  Ada 
programming  language. 
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CHAPTER  2 

IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for  withdrawing  each  test  is 
available  from  either  the  AVO  or  the  AVF.  The  publication  date  for  this  list  of  withdrawn  tests  is  2 
August  1991. 


E28005C 

B28006C 

C32203A 

C34006D 

C35508I 

C35508J 

C35508M 

C35508N 

C35702A 

C35702B 

B41308B 

C43004A 

C45114A 

C45346A 

C45612A 

C45612B 

C45612C 

C45651A. 

C46022A 

B49008A 

B49008B 

A74006A 

C74308A 

B83022B 

B83022H 

B83025B 

B83025D 

C83026A 

B83026B 

C83041A 

B85001L 

C86001F 

C94021A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

BD4008A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

AD7206A 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2117A 

CE2117B 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3116A 

CE3118A 

CE3411B 

CE3412B 

CE3607B 

CE3607C 

CE3607D 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant  for  a  given  Ada 
implementation.  Reasons  for  a  test’s  inapplicability  may  be  supported  by  documents  issued  by  the  ISO 
and  the  AJPO  known  as  Ada  Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For 
this  implementation,  the  following  tests  were  determined  to  be  inapplicable  for  the  reasons  indicated; 
references  to  Ada  Commentaries  are  included  as  appropriate. 


The  following  159  tests  have  floating-point  type  declarations  requiring  more  digits  than 
SYSTEM.MAX_DIGITS: 


C241130..Y  (11  tests) 
C35706O..Y  (11  tests) 
C35708O..Y  (11  tests) 
C452410..Y  (11  tests) 
C454210..Y  (11  tests) 


C35705O..Y  (11  tests) 
C35707O..Y  (11  tests) 
C35802O..Z  (12  tests) 
C453210..Y  (11  tests) 
C455210..Z  (12  tests) 
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C455240..Z  (12  tests)  C456210..Z  (12  tests) 

C456410..Y  (11  tests)  C46012O..Z  (12  tests) 


The  following  20  tests  check  for  the  predefined  type  LONG_INTEGER;  for  this  implementation, 
there  is  no  such  type: 


C35404C 

C45231C 

C45304C 

C45411C 

C45412C 

C45502C 

C45503C 

C45504C 

C45504F 

C45611C 

C45613C 

C45614C 

C45631C 

C45632C 

B52004D 

C55B07A 

a55B09C 

B86001W 

C86006C 

CD7101F 

C35713B,  C45423B.  B86001T  and  C86006H  check  for  the  predeHned  type  SHORT_FLOAT;  for  this 
implementation,  there  is  no  such  type. 


C45423A,  C45523A,  and  C45622A  check  that  the  proper  exception  is  raised  if 

MACHINE_OVERFLOWS  is  TRUE  ana  the  results  of  various  floating-point  operations  lie  outside 
the  range  of  the  base  type;  for  this  implementation,  MACHINE_OVERFLOWS  is  FALSE. 

C45531M..P  and  C45532M..P  (8  tests)  check  fixed-point  operations  for  types  that  require  a 
SYSTEM.MAX_MANTISSA  of  47  or  greater;  for  this  implementation,  MAX_MANTISSA  is  less 
than  47. 

B86001Y  uses  the  name  of  a  predefined  fixed-point  type  other  than  type  DURATION;  for  this 
implementation,  there  is  no  such  type. 

C96005B  uses  values  of  type  DURATION’S  base  type  that  are  outside  the  range  of  type 
DURATION;  for  this  implementation,  the  ranges  are  the  same. 

CA2009A,  CA2009C..D  (2  tests),  and  CA2009F  instantiate  generic  units  before  their  bodies  are 
compiled;  this  implementation  creates  a  dependence  on  generic  units  as  allowed  by  AI-00408  and  AI- 
00506  such  that  the  compilation  of  the  generic  unit  bodies  makes  the  instantiating  units  obsolete. 
(See  Section  2.3). 

CD1009C  checks  whether  a  length  clause  can  specify  a  non-default  size  for  a  floating-point  type;  this 
implementation  does  not  support  such  sizes. 

CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  length  clauses  to  specify  non-default 
sizes  for  access  types;  this  implementation  does  not  support  such  sizes. 

CD2B15B  checks  that  STORAGE_ERROR  is  raised  when  the  storage  size  specified  for  a  collection 
is  too  small  to  hold  a  single  value  of  the  designated  type;  this  implementation  allocates  more  space 
than  was  specified  by  tne  length  clause,  as  allowed  by  AI-(X)558. 
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The  following  264  tests  check  operations  on  sequential,  text,  and  direct  access  files;  this 
implementation  does  not  support  external  files: 


CE2102A..C  (3) 

CE2102G..H  (2) 

CE2102K 

CE2102N..Y  (12) 

CE2103C..D  (2) 

CE2104A..D  (4) 

CE2105A..B  (2) 

CE2106A..B  (2) 

CE2107A..H  (8) 

CE2107L 

CE2108A..H  (8) 

CE2109A..C  (3) 

CE2110A..D  (4) 

CE2111A..I  (9) 

CE2115A..B  (2) 

CE2120A..B  (2) 

CE2201A..C  (3) 

EE2201D..E  (2) 

CE2201F..N  (9) 

CE2203A 

CE2204A..D  (4) 

CE2205A 

CE2206A 

CE2208B 

CE2401A..C  (3) 

EE2401D 

CE2401E..F  (2) 

EE2401G 

CE2401H..L  (5) 

CE2403A 

CE2404A..B  (2) 

CE2405B 

CE2406A 

CE2407A..B  (2) 

CE2408A..B  (2) 

CE2409A..B  (2) 

CE2410A..B  (2) 

CE2411A 

CE3102A..C  (3) 

CE3102F..H  (3) 

CE3102J..K  (2) 

CE3103A 

CE3104A..C  (3) 

CE3106A..B  (2) 

CE3107B 

CE3108A..B  (2) 

CE3109A 

CE3110A 

CE3111A..B  (2) 

CE3111D..E  (2) 

CE3112A..D  (4) 

CE3114A..B  (2) 

CE3115A 

CE3119A 

EE3203A 

EE3204A 

CE3207A 

CE3208A 

CE3301A 

EE3301B 

CE3302A 

CE3304A 

CE3305A 

CE3401A 

CE3402A 

EE3402B 

CE3402C..D  (2) 

CE3403A..C  (3) 

CE3403E..F  (2) 

CE3404B..D  (3) 

CE3405A 

EE3405B 

CE3405C..D  (2) 

CE3406A..D  (4) 

CE3407A..C  (3) 

CE3408A..C  (3) 

CE3409A 

CE3409C..E  (3) 

EE3409F 

CE3410A 

CE3410C..E  (3) 

EE3410F 

CE3411A 

CE3411C 

CE3412A 

EE3412C 

CE3413A..C  (3) 

CE3414A 

CE3602A..D  (4) 

CE3603A 

CE3604A..B  (2) 

CE3605A..E  (5) 

CE3606A..B  (2) 

CE3704A..F  (6) 

CE3704M..O  (3) 

CE3705A..E  (5) 

CE3706D 

CE3706F..G  (2) 

CE-3804A..P  (16) 

CE3805A..B  (2) 

CE3806A..B  (2) 

CE3806D..E  (2) 

CE3806G..H  (2) 

CE3904A..B  (2) 

CE3905A..C  t^l) 

CE3905L 

CE-3906A..C  (3) 

CE3906E..F  (2) 

2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  25  tests. 

The  following  test  was  split  into  two  or  more  tests  because  this  implementation  did  not  report  the 
violations  of  the  Ada  Standard  in  the  way  expected  by  the  original  tests. 

B97103E 

C45524A..K  (11  tests)  were  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  These  tests 
expect  that  a  repeated  division  will  result  in  zero;  but  the  Ada  standard  only  requires  that  the  result 
lie  in  the  smallest  safe  interval.  Thus,  the  tests  were  modified  to  check  that 
the  result  was  within  the  smallest  safe  interval,  by  adding  the  following  code  after  line  141;  the 
modified  tests  were  passed: 
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ELSIF  VAL  <=  F’SAFE_SMALL  THEN  COMMENT  ("UNDERFLOW  SEEMS  GRADUAL"); 

BC3204C,  BC3204D,  BC3205C  and  BC3205D  were  graded  passed  by  Processing  Modification  as 
directed  by  the  AVO.  These  tests  check  that  instantiations  of  generic  units  with  unconstrained  types 
as  generic  actual  parameters  are  illegal  if  the  generic  bodies  contain  uses  of  the  types  that  require 
a  constraint.  However,  the  generic  bodies  are  compiled  after  the  units  that  contain  the  instantiations, 
and  this  implementation  creates  a  dependence  of  the  instantiating  units  on  the  generic  units  as 
allowed  by  AI-0040b  AI-00506  such  that  the  compilation  of  the  generic  bodies  makes  the 

instantiating  units  obsolete--no  errors  are  detected.  The  processing  of  these  tests  was  modified  by 
re-compiling  the  obsolete  units;  all  intended  errors  were  then  detected  by  the  compiler. 

CA2009A,  CA2009C..D  (2  tests),  and  CA2009F  were  graded  inapplicable  by  Evaluation  Modification 
as  directed  by  the  AVO.  These  tests  instantiate  generic  units  before  those  units’  bodies  are  compiled; 
this  implementation  creates  dependences  as  allowed  by  AI-00408  &  AI-(X)506 -such  that  the 
compilation  of  the  generic  unit  txxiies  makes  the  instantiating  units  obsolete,  and  the  objectives  of 
these  tests  cannot  be  met. 

CE2103A,  CE2103B,  and  CE3107A  were  graded  inapplicable  by  Evaluation  Modification  as  directed 
by  the  AVO.  The  tests  abort  with  an  unhandled  exception  when  USE_ERROR  is  raised  on  the 
attempt  to  create  an  external  file.  This  is  acceptable  behaviour  because  this  implementation  does  not 
support  external  files  (cf.  AI-00332). 

CE3806G  was  graded  inapplicable  by  Evaluation  Modification  as  directed  by  the  AVO.  This  test  is 
inapplicable  to  implementations  that  do  not  support  external  files.  However,  the  test  incorrectly 
continues  execution  after  handling  NAME_ERROR  at  line  42  (and  calling 
REPORT.NOT_APPLICABLE),  and  the  subsequent  attempt  to  create  a  file  results  in  the  test 
aborting  with  an  unhandled  NAME_ERROR  exception. 

CE3901A  was  graded  passed  by  Test  Modification  as  directed  by  the  AVO.  This  test  expects  that 
implementations  that  do  not  support  external  files  will  raise  USE_ERROR  on  the  attempt  to  create 
a  file  at  line  52;  this  implementation  raises  NAME_ERROR,  as  allowed  by  AI-00332.  The  test  was 
modified  by  inserting  ’  |  NAME_ERROR’  into  the  exception  choice  at  line  52,  and  the  modified  test 
was  passed. 
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CHAPTERS 

PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described  by  the  information  given  in  the 
initial  pages  of  this  report  together  with  the  following  additional  details. 

Host  Memory  Size:  37  MBytes 

Communication  Link:  RS232 

Bus  system:  VME  BUS 

For  technical  information  about  this  Ada  implementation,  contact: 

Tim  Magness 

SD-Scicon  UK  Limited 

Pembroke  House 

Pembroke  Broadway 

Camberley 

Surrey 

GU25  3XD 

For  sales  information  about  this  Ada  implementation,  contact: 

Colin  Foster 
SD-Scicon  UK  Limited 
Pembroke  House 
Pembroke  Broadway 
Camberley 

■  ~  Surrey 

GU25  3XD 

Testing  of  this  Ada  implementation  was  conducted  at  the  customer’s  site  by  a  validation  team  from 
the  AVF. 
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3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test  of  the  customized  test 
suite  in  accordance  with  the  Ada  Programming  Language  Standard,  whether  the  test  is  applicable  or 
inapplicable;  otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  (inapplicable  and  applicable),  a  result  was  obtained  that  conforms  to  the  Ada 
Programming  Language  Standard. 

The  list  of  items  below  gives  the  number  of  ACVC  tests  in  various  categories.  All  tests  were 
processed,  except  those  that  were  withdrawn  because  of  test  errors  (item  b;  see  section  2.1),  those 
that  require  a  floating-point  precision  that  exceeds  the  implementation’s  maximum  precision  (item 
e;  see  section  2.2),  and  those  that  depend  on  the  support  of  a  file  system  --  if  none  is  supported  (item 

d).  All  tests  passed,  except  those  that  are  listed  in  sections  2.1  and  2.2  (cc  anted  in  items  b  and  f, 
below). 


a)  Total  Number  of  Applicable  Tests  3604 

b)  Total  Number  of  Withdrawn  Tests  95 

c)  Processed  Inapplicable  Tests  471 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point  Precision  Tests  0 

f)  Total  Number  of  Inapplicable  Tests  471(c-bd-f  e) 

g)  Total  Number  of  Tests  for  ACVC  1.11  4170  (a-)-b+0 
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3.3  TEST  EXECUTION 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was  taken  on-site  by  the 
validation  team  for  processing. 

The  contents  of  the  Magnetic  tape  were  loaded  onto  a  VAX  8600  and  were  transferred  via  DECnet 
to  the  host  computer  system. 

After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of  tests  was  processed  by  the  Ada 
implementation. 

The  tests  were  compiled  and  linked  on  the  host  computer  system,  as  appropriate.  The  executable 
images  were  transferred  to  the  target  computer  system  by  the  communications  link  described  above, 
and  run.  The  results  were  captured  on  the  host  computer  system. 

Testing  was  performed  using  command  scripts  provided  by  the  customer  and  reviewed  by  the 
validation  team.  See  Appendix  B  for  a  complete  listing  of  the  processing  options  for  this 
implementation.  It  also  indicates  the  default  options.  The  options  invoked  explicitly  for  validation 
testing  during  this  test  were: 

/LIST  used  for  tests  requiring  compilations  lists 

/DEV=DAY_0  in  house  compiler  option  to  remove  extraneous  listing  information  eg  dates 

and  headers. 


Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on  magnetic  tape  and  archived 
at  the  AVF.  The  listings  examined  on-site  by  the  validation  team  were  also  archived. 


Validition  Sunary  laport 


aVF_VS«_90502/80 
n  Ada  IC68040  Vartion  1.2 


B-Sctnn  UK  Liaitad 


Chaptar  3  -  Pape  3  of  3 


MACRO  PARAMETERS 


APPENDIX  A 

MACRO  PARAMETERS 

This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC.  The  meaning  and 
purpose  of  these  parameters  are  explained  in  [UG89].  The  parameter  values  are  presented  in  two 
tables.  The  Erst  table  lists  the  values  that  are  defined  in  terms  of  the  maximum  input-line  length, 
which  is  the  value  for  $MAX_IN_LEN"also  listed  here.  These  values  are  express^  here  as  Ada 
string  aggregates,  where  "V"  represents  the  maximum  input-line  length. 

Macro  Parameter 

Macro  Value 

$MAX_IN_LEN 

255 

$B1G_ID1 

(1..V-1  =>  ’A’,  V  =  >  ’1’) 

$BIG_ID2 

(1..V-1  =>  ’A’,  V  =>  ’2’) 

$BIG_ID3 

(1..V/2  =>  ’A’)  &  ’3’  &  (l..V-l-Vy2  «>  ’A’) 

SBIG_ID4 

(1..V/2  =>  ’A’)  &  ’4’  &  (1..V-1-V/2  =>  ’A’) 

$BIG_INT_LIT 

(1..V-3  =>  ’O’)  &  "298" 

SBIG_REAL_LIT 

(1..V-5  =>  ’O’)  &  "690.0" 

$B1G_STRING1 

’"’  &  (1..V/2  =>  ’A’)  &  ’"’ 

$BIG_STRING2 

’"’  &  (1..V-1-V/2  =>  ’A’)  &  ’1’  &  ’"’ 

$BLA]^ 

(1..V-20  =>  ”) 

$MAX  LEN  INT  BASED  LITERAL 

"2:"  &  (1..V-5  =>  ’O’)  &  "11:" 

$MAX_LEN_REAL_BASED. 

LITERAL 

"16:"  &  (1..V-7  =>  ’O’)  &  "F.E:" 

SMAX_STRING_LrTERAL 

•"’  &  (1..V-2  *>  ’A’)  & 

The  following  table  lists  all  of  the  other  macro  parameters  and  their  respective  values. 
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Macro  Parameter 

Macro  Value 

$ACC_SIZE 

32 

$ALIGNMENT 

1 

$COUNT_LAST 

2147483647 

$DEFAULT_MEM_SIZE 

2147483647 

$DEFAULT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

MC68040 

$DELTA_DOC 

2#1.0#E-31  -  . 

$ENTRY_ADDRESS 

SYSTEM,TO_ADDRESS(16#68#) 

$ENTRY_ADDRESS1 

SYSTEM.TO_ADDRESS(16#6C#) 

SENTRY_ADDRESS2 

SYSTEM.TO_ADDRESS(16#70#) 

$FIELD_LAST 

255 

$FILE_TERMINATOR 

«  t 

$FIXED_NAME 

NO_SUCH_TYPE 

SFLOAT_NAME 

LONG_LONG_FLOAT 

$FORM_STRING 

ffff 

$FORM_STRING2 

"CANNOT_RESTRICr_FILE_CAPACmr 

$greAter_than_duration 

131072.0 

SGREATER  THAN  DURATION  BASE  LAST 

131073.0 

$GREATER  THAN  FLOAT  BASE  LAST 

3.40283E+38 

SGREATER  THAN  FLOAT  SAFE  LARGE 

4.255354E+37 

SGREATER  THAN  SHORT  FLOAT  SAFE  LARGE 

^0_SUCH_TYPE" 
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SHIGH  PRIORITY 


15 


SILLEGAL  EXTERNAL_FILE_NAME1 

ILLEGAL_EXTERNAL_FILE_NAME1 

$ILLEGAL_EXTERNAL  FILE  NAME2 

ILLEGAL_EXTERNAL_FILE_NAME2 

$INAPPROPRIATE_LINE_LENGTH  -1 

SINAPPROPRIATE  PAGE  LENGTH 


$INCLUDE_PRAGMA1 

$INCLUDE_PRAGMA2 

$INTEGER_nRST 

SINTEGER.LAST 

$INTEGER_LAST_PLUS_1 

$INTERFACE_LANGUAGE 

SLESS  THAN  DURATION 


PRAGMA  INCLUDE  ("A28006D1.TST") 

PRAGMA  INCLUDE  ("B28006D2.TS’r) 

-2147483648 

2147483647 

2147483648 

ASSEMBLER 

-131072.0 


$LESS_THAN_DURATION_BASE_FIRST 

-131073.0 


$LINE_TERMINATOR 

$LOW_PRIORrTY 

$MACtlINE_CODE_STATEMENT 

$MACHINE_CODE_TYPE 

$MANTISSA_DOC 

$MAX_DIGITS 

$MAX_INT 

$MAX_INT_PLUS_1 

$MIN_INT 


0 

OPERANDLESS_INSr(OPCODE=  >NOP); 
OPERANDLESS_INST 
31 
18 

2147483647 

2_147_483_648 

-2147483648 
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SNAME 

$NAME_LIST 

$NAME_SPECIHCATIONl 

$NAME_SPECmCATION2 

$NAME_SPECIFICATION3 

$NEG_BASED_INT 

$NEW_MEM_SIZE 

$NEW_STOR_UNIT 

$NEW_SYS_NAME 

$PAGE_TERMINATOR 

$RECORD_DEFINmON 

$RECORD_NAME 

STASK_SIZE 

STASK_STORAGE_SIZE 

STICK 

SVARIABLE_ADDRESS 

SVARIABLE_ADDRESS1 

$VARIABLE_ADDRESS2 

$YOUR_PRAGMA 


SHORT_SHORT_INTEGER 

MC68040 

NO_SUCH_NAME 

NO_SUCH_NAME 

NO_SUCH_NAME 

16#FFFF_FFFF# 

123456 

8 

MC68040 

i  » 

RECORD  OPCODE  :  OPERANDLESS  OP;  END 
RECORD; 

OPERANDLESS_INST 

32 

2048 

162.5E-6 

SYSTEM.TO_ADDRESS(16#40C#) 

SYSTEM.TO_ADDRESS(16#408#) 

SYSTEM.TO_ADDRESS(16#404#) 

EXPORT_OBJECT 
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APPENDIX  B 

COMPILATION  SYSTEM  OPTIONS 


Include  a  separate  list  of  options  and  their  meanings  for  each  of  the  software  systems  used  in  this 
validation.  A  software  system  must  be  the  compiler  and  could  be  the  linker,  the  loader,  the  binder, 
etc.  (Version  numbers  should  be  included) 
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XDADA 


XDADA 

Invokes  the  XD  Ada  compiler  to  compile 

:  one  or  more  source  files. 

Format 

XDADA  file-spec[,...] 

Command  Qualifiers 

Defaults 

/LIBRARY  *  directory-spec 

/LIBRARY.  XDADASLIB 

Positional  Qualifiers 

Defaults 

/{NOIANALYSIS.DATAI  -  file-spec] 

/NOANALYSIS.DATA 

/(NOjCHECK 

See  text. 

/[NOjCOPY.SOURCE 

/COPY.SOURCE 

/[NOjDEBUGI- (option!... .Di 

/DEBUG -ALL 

/[NOjDIAGNOSTICS!- file-spec) 

/NODIAGNOSTICS 

/[N01ERR0R_LIMIT[-n] 

/ERROR_LIMIT.30' 

/[NOjLIST!- file-spec] 

/NOLIST 

/(NO]LOAD(- option] 

/LOAD -REPLACE 

/INO]MACHINE_CODE|  -  option] 

/NOMACHINE.CODE 

/[NO]NOTE_SOURCE 

/NOTE.SOURCE 

/!NO]OPTIMlZEl  -  option) 

See  text. 

/(NO]PREDEFINED_UNIT 

/nopredefined.unit 

/(NO]SHOW[- option] 

/SHOW -PORTABILITY 

/[NO]SYNTAX„ONLY 

/NOSYNTAX.ONLY 

/(NOlWARNINGS!-  (option!.... Dl 

See  text. 

Prompt 

.File: 

Command  Parameters 


file-spec 

Specifies  one  or  more  XD  Ada  source  files  to  be  compiled.  If  you  do 
not  specify  a  file  type,  the  compiler  uses  the  default  fUe  type  of  .ADA. 
No  wildcard  characters  are  allowed  in  the  file  specifications. 
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XDADA 


If  you  specify  several  source  files  as  arguments  to  the  XDADA  com¬ 
mand,  you  must  separate  adjacent  file  specifications  with  a  comma  ( , ). 
If  you  specify  more  than  one  input  file,  you  must  separate  adjacent  file 
specifications  with  a  comma  (, ),  You  cannot  use  a  plus  sign  (  -t- )  to 
separate  file  specifications. 


Description 

The  XDADA  command  is  one  of  four  commands  used  to  compile  com¬ 
pilation  units.  The  other  three  are  the  XDACS  COMPILE,  RECOMPILE 
and  LOAD  commands. 

The  XDADA  command  can  be  used  at  any  time  to  compile  one  or 
more  source  files  (.ADA).  Source  files  are  compiled  in  the  order  they 
appear  on  the  command  line.  If  a  source  file  contains  more  than  one 
compilation  unit,  they  are  compiled  in  the  order  they  appear  in  the 
source  file. 

The  XDADA  command  compiles  units  in  the  context  of  the  current 
program  library.  Whenever  a  compilation  unit  is  compiled  without 
error,  the  current  program  library  is  updated  with  the  object  module 
and  other  products  of  the  compilation. 


Command  Qualifiers 

/LIBRARY  s  directory-spec 

Specifies  the  program  library  that  is  to  be  the  current  program  library 
for  the  duration  of  the  compilation.  The  directory  specified  must  be  an 
already  existing  XD  Ada  program  library.  No  wildcard  characters  are 
allowed  in  the  directory  specification. 

By  default,  the  current  program  library  is  the  program  library  last 
specified  in  an  XDACS  SET  LIBRARY  command.  The  logical  name 
XDADASLIB  is  assigned  to  the  program  library  specified  in  an  XDCAS 
SET  LIBRARY  command. 


Positional  Qualifiers 

lANALYSIS.DA  TA[ = file-spec] 

INOANALYSIS_DATA  (D) 

Controls  whether  a  data  analysis  file  containing  source  code  cross- 
reference  and  static  analysis  information  is  created.  The  data  analysis 
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XDADA 


file  is  supported  only  for  use  with  DIGITAL  layered  products,  such  as 
the  VAX  Source  Code  Analyzer. 

One  data  analysis  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  data  analysis  files  is  the  current  default  directory. 
The  default  file  name  is  the  name  of  the  source  fife  being  compiled. 
The  default  file  type  is  ANA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  data  analysis  file  is  created. 

/CHECK 

INOCHECK 

Controls  whether  ait  run-time  checks  are  suppressed.  The  /NOCHECK 
qualifier  is  equivalent  to  having  all  possible  SUPPRESS  pragmas  in  the 
source  code. 

Explicit  use  of  the  /CHECK  qualifier  overrides  any  occurrences  of  the 
pragmas  SUPPRESS  and  SUPPRESS.ALL  in  the  source  code,  without 
the  need  to  edit  the  source  code. 

By  default,  run-time  checks  are  suppressed  only  in  cases  where  a 
pragma  SUPPRESS  or  SUPPRESS_ALL  appears  in  the  source. 

See  the  Reference  Manual  for  the  Ada  Programming  Language  for  more 
information  on  the  pragmas  SUPPRESS  and  SUPPRESS.ALL. 

/COPY_SOURCE  (D) 

/NOCOPY^SOURCE 

Controls  whether  a  copied  source  file  (.ADC)  is  created  in  the  current 
program  library  when  a  compilation  unit  is  corrmiled  without  error.  The 
RECOMPILE  command  (and  thus  the  COMPILE  command)  requires 
that  a  copied  source  file  exist  in  the  current  program  library  for  any  unit 
that  is  to  be  recompiled. 

By  default,  a  copied  source  file  is  created  in  the  current  program  library 
when  a  unit  is  compiled  without  error. 

/DEBUG[ = (optlonl, . . .])]  (D) 

/NODEBUG 

Controls  which  compiler  debugging  options  are  provided.  You  can 
debug  XD  Ada  programs  with  the  XD  Ada  Debugger.  You  can  request 
the  following  options; 
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ALL 


Provides  both  SYMBOLS  and  TRACES ACK. 


NONE 

(NOISYMBOLS 

INOITRACEBACK 


Provides  neither  SYMBOLS  nor  TRACEBACK. 

Controls  whether  debugger  symbol  records  are  in¬ 
cluded  in  the  object  file. 

Controls  whether  traceback  information  (a  subset  of 
the  debugger  symbol  information)  is  included  in  the 
object  file. 


By  default,  both  debugger  symbol  records  and  traceback  information  are 
included  in  the  object  file  (/DEBUG  ••  ALL,  or  equivalently:  /DEBUG). 

/DIAGNOSTICS[»  file-spec] 

/NODIAGNOSTICS  (D) 

Controls  whether  a  diagnostics  file  containing  compiler  messages  and 
diagnostic  information  is  created.  The  diagnostics  file  is  supported  only 
for  use  with  DIGITAL  layered  products,  such  as  the  VAX  I^nguage- 
Sensitive  Editor. 

One  diagnostics  file  is  created  for  each  source  file  compiled.  The 
default  directory  for  diagnostics  files  is  the  current  default  directory. 
The  default  file  name  is  the  name  of  the  source  file  being  compiled. 
The  default  file  type  is  .DIA.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

By  default,  no  diagnostics  file  is  created. 

IERROR_UMIT[=n] 

I  NOERROR  JlIMIT 

Controls  whether  execution  of  the  XDADA  command  for  a  given 
compilation  unit  is  terminated  upon  the  occurrence  of  the  nth  E-Ievel 
enor  within  that  unit. 

Error  counts  are  not  accumulated  across  a  sequence  of  compilation 
units.  If  the  /ERROR.UMIT  -  n  option  is  specified,  each  compilation 
unit  may  have  up  to  n-1  errors  without  tenrinating  the  compilation. 
When  the  error  limit  is  reached  within  a  compilation  unit,  compilation  of 
that  unit  is  terminated,  but  compilation  of  subsequent  units  continues. 

The  /ERROR_LIMIT  -  0  option  is  equivalent  to  ERROR.LIMIT- 1. 

By  default,  execution  of  the  XDADA  command  is  terminated  for  a  given 
compilation  unit  upon  the  occurrence  of  the  30th  E-level  error  uithin 
that  unit  (equivalent  to  /ERROR_LIMrT»30). 
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I  LIST[  =  file-spec] 

INOUST  (D) 

Controls  whether  a  listing  file  is  created.  One  listing  file  is  created 
for  each  source  file  compiled.  The  default  directory  for  listing  files  is 
the  current  default  directory.  The  default  file  name  is  the  name  of  the 
source  file  being  compiled.  The  default  file  type  is  .US.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  the  XDADA  command  does  not  create  a  listing  file. 

/ LOAD]  =  option]  (D) 

/NOLOAD 

Controls  whether  the  current  program  library  is  updated  with  the 
successfully  processed  units  contained  in  the  specified  source  files. 
Depending  on  other  qualifiers  specified  (or  not  specified)  with  the 
XDADA  command,  processing  can  involve  full  compilation,  syntax 
checking  only,  and  so  on.  The  /NOLOAD  qualifier  causes  the  units 
in  the  specified  source  files  to  be  processed,  but  prevents  the  current 
program  library  from  being  updated. 

You  can  specify  the  following  option; 

[NO|REPLACE  Controls  whether  a  unit  added  to  the  current 

program  library  replaces  an  existing  unit  with  the 
same  name.  If  you  specify  the  NOREPLACE  option, 
the  unit  is  added  to  the  current  program  library  ortly 
if  no  existing  unit  tas  the  same  name,  except  if  the 
new  unit  is  the  corresponding  body  of  an  existing 
specification  or  vice  versa. 

By  default,  the  curren  program  library  is  updated  with  the  success¬ 
fully  procpcied  units,  and  a  unit  added  to  the  current  program  library 
replaces  an  existing  unit  with  the  same  name. 

IMACHINE_CCDe]  =  option] 

/NOMACHINE_COUB  (D) 

Controls  whether  generated  machine  code  (approximating  assembly 
language  notation)  is  included  in  the  listing  file. 

You  cam  specify  one  of  the  following  options: 
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SYMBOUC:NONE  Provides  machine  code  listing  with  no  annotation. 

SYMBOUCiNORMAL  Provides  machine  code  in  the  listing  hie;  where 

possible,  instructions  are  annotated  with  simple  Ada 
names. 

SYMB0UC;MAX1MAL  Provides  machine  code  in  the  listing  file;  where 

possible,  instructions  are  annotated  with  Ada  names, 
in  expanded  form  if  necessary. 

The  /MACHINE  CODE  qualifier  without  options  is  equivalent  to 
/MACHINE.CODE  -  SYMBOUCiNORMAL. 

iNOTE_SOURCE  (D) 

/NONOTE_SOURCE 

Controls  whether  the  file  specification  of  the  source  file  is  noted  in  the 
program  library  when  a  ui\it  is  compiled  without  error.  The  COMPILE 
command  uses  this  information  to  locate  revised  source  files. 

By  default,  the  file  specification  of  the  source  file  is  noted  in  the  pro¬ 
gram  library  when  a  unit  is  compiled  without  error. 

IOPTIMIZE[»(optlon(,  ...  J) 

/NOOPTIMIZE 

Controls  the  level  of  optimization  that  is  applied  in  producing  the 
compiled  code.  You  can  specify  one  of  the  following  primary  options: 

Provides  full  optimization  with  time  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZE(SPACE)  in  the  source  code. 

Provides  full  optimization  with  space  as  the  primary 
optimization  criterion.  Overrides  any  occurrences  of 
the  pragma  OPTIMIZECTIME)  in  the  source  code. 

Suggested  when  active  development  of  a  program 
is  in  progress.  Provides  some  optimization,  but 
development  considerations  and  ease  of  debugging 
take  preference  over  optimization.  This  option 
overrides  pragmas  that  establish  a  dependence  on  a 
subprogram  (the  pragma  INLINE),  and  thus  reduces 
the  need  for  recompilations  when  such  bodies  are 
modified. 

none  Provides  no  optimization.  Suppresses  expansions  in 

line  of  subprograms,  including  those  specified  by  the 
pragma  INLINE. 

The  /NOOPTIMIZE  qualifier  is  equivalent  to  /OPTIMIZE -NONE. 


TIME 

SPACE 

DEVELOPMENT 
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By  default,  the  XD.ADA  command  applies  full  optimization  with  time 
as  the  primary  optimization  criterion  (like  /OPTIMIZE -TIME,  but 
observing  uses  of  the  pragma  OPTIMIZE). 

The  /OPTIMIZE  qualifier  also  has  a  set  of  secondary  options  that  you 
can  use  separately  or  together  with  the  primary  options  to  override  the 
default  behavior  for  inline  expansion  and  code  motion. 

The  INLINE  secondary  option  can  have  the  following  values: 

INUNE:NONE  Disables  subprogram  expansion  in  line.  This  option 

overrides  any  occurrences  of  the  pragma  INLINE 
in  the  source  code,  without  having  to  edit  the 
source  file.  It  also  disables  implicit  expansion  in 
line  of  subprograms.  {Implicit  expansion  in  line  means 
that  the  compiler  assumes  a  pragma  INLINE  for 
certain  subprograms  as  an  optimization.)  A  call  to  a 
subprogram  in  another  unit  is  not  expanded  in  line, 
regardless  of  the  /OPTIMIZE  options  in  effect  when 
that  unit  was  compiled. 

INLINE:NORMAL  Provides  normal  subprogram  expansion  in  line. 

Subprograms  to  which  an  explicit  pragma  INLINE 
applies  are  expanded  in  line  under  ceciain  condi¬ 
tions.  In  addition,  some  subprograms  are  implicitly 
expanded  in  line.  The  compiler  assumes  a  pragma 
INLINE  for  calls  to  some  small  local  subprograms 
(subprograms  that  are  declared  in  the  same  unit  as 
the  unit  in  which  the  call  occurs). 

INLINE: SUBPROGRAMS  Provides  maximal  subprogram  expansion  in  line.  In 

addition  to  the  normal  subprogram  expansion  in 
line  that  occurs  when  INLINE:  NORMAL  is  specified, 
this  option  results  in  implicit  expansion  in  line  of 
some  small  subprograms  declared  in  other  units. 

The  compiler  assumes  a  pragma  INLINE  for  any 
subprogram  if  it  improves  execution  speed  and 
reduces  code  size.  This  option  may  establish  a 
dependence  on  the  body  of  another  unit,  as  would  be 
the  case  if  a  pragma  INLINE  v,fere  specified  explicitly 
in  the  source  code. 
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INLJNE:MAXIMAL  Provides  maximal  subprogram  expansion  in  line. 

Maximal  subprogram  expansion  in  line  occurs  as  for 
1NUNE:SUBPR0GRAMS. 

INLINE:GENERICS  Provides  normal  subprogram  inline  expansion  and 

maximal  generic  inline  expansion.  With  this  option, 
subprogram  inline  expansion  occurs  in  the  same 
manner  as  for  INL1NE;N0RMAL.  The  compiler 
assumes  a  pragma  INUNE.GENERIC  for  every 
instantiation  in  the  unit  being  compiled  uiUess 
a  generic  body  is  not  available.  This  option  may 
establish  a  dependence  on  the  body  of  another  unit, 
as  would  be  the  case  if  a  pragma  INUNE.GENERIC 
were  specified  explicitly  in  the  source  code. 

The  MOTION  secondary  option  can  have  the  following  values; 
MOTIONiNONE  Disables  code  motion  optimizations. 

MOTION; LOOPS  Permits  code  motion  optimization  of  loops.  Where 

the  compiler  detects  that  a  loop  body  contains 
invariant  processing,  it  may  generate  code  in  which 
this  processing  is  performed  before  entry,  tp  the  loop 
instead  of  within  the  loop.  “  ' 

MOTION; MAXIMAL  Permits  all  code  motion  optimizations.  In  addition 

to  the  optimization  of  loops  that  occurs  when 
MOTION: LOOPS  is  specified,  this  option  permits 
analogous  optimization  of  if  and  case  statements: 
where  the  compiler  detects  that  the  branches  of  an  if 
or  case  statement  contain  common  processing,  it  may 
generate  code  in  which  this  processing  is  performed 
before  evaluation  of  the  corresponding  condition  or 
case  expression  instead  of  within  the  branches. 

By  default,  the  /OPTIMIZE  qualifier  primary  options  have  the  follovring 
secondary-option  values: 

/OPTIMIZE -TIME  -(INUNE:NORMAL.MOTION;LOOPS) 

/OPTIMIZE  -  SPACE  -  (INUNE: NORM AL. MOTION : MAXIMAL) 

/OPTIMIZE  -  DEVELOPMENT  >  ( INUNE: NONE,  MOTION :  NONE) 

/OPTIMIZE -NONE  -(1NUNE:N0NE,M0T10N:N0NE) 

I  PREDEFINED  JJNIT 
/NOPREDEFINEDJJNIT  (D) 

Controls  the  compilation  of  package  SRUN  TIME_SYSTEM,  pack¬ 
age  STASKING.SYSTEM,  and  package  MACHINE.CODE.  You  must 
specify  this  qualifier  in  order  to  be  able  to  compile  these  packages. 
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The  qualifier  is  not  required  for  the  compilation  of  any  other  source 
files.  See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  more 
information. 

By  default,  /PREDEFINED. UNIT  is  omitted. 

/SHOW[= option]  (D) 

/NOSHOW 

Controls  the  listing  file  options  included  when  a  listing  file  is  provided. 
You  can  specify  one  of  the  following  options: 

ALL  Provides  all  listing  file  options. 

(NOIPORTABIUTY  Controls  whether  a  program  portability  summary 

is  included  in  the  listing  file.  By  default,  the 
XDADA  command  provides  a  portability  sum¬ 
mary  (/SHOW- PORTABILITY).  See  Appendix  E 
for  details  of  what  can  be  included  in  a  porta¬ 
bility  summary.  See  Chapter  5  of  Version  2.0  of 
Developing  Ada  Programs  on  VMS  Systems  for  more 
information  on  program  portability. 

NONE  Provides  none  of  the  listing  file  options  (same  as 

/NOSHOW). 

By  default,  the  XDADA  command  provides  a  portability  summary 
(/SHOW  -  PORTABIUTY). 

/SYNTAXjONLY 
INOSYNTAXJONLY  (D) 

Controls  whether  the  source  file  is  to  be  checked  only  for  correct  syntax. 
If  you  specify  the  /SYNTAX.ONLY  qualifier,  other  compiler  checks  are 
not  performed  (for  example,  semantic  analysis,  type  checking,  and  so 
on). 

By  default,  the  compiler  performs  all  checks. 

WARNINGS]  a  (mossago-optlon],...])] 

INOWARNINGS 

Controls  which  categories  of  informational  (Mevel)  and  warning  (W- 
level)  messages  are  displayed  and  where  those  messages  are  displayed. 
You  can  specify  any  combination  of  the  following  message  options; 

WARNINGS;  {destination[,...\) 

NOWARNINGS 

WEAK, WARNINGS:  {destination\.. . . )) 
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NOVVEAK.  WARNINGS 

SUPPLEMENTAL;  (destinationl,. . . )) 
NOSUPPLEMENTAL 


COMPILATION.NOTES:  (destinationl....]) 
NOCOMPILATION.NOTES 

STATUS:  (destination],... \) 

NOSTATUS 


The  possible  values  of  destination  are  ALL,  NONE,  or  any  combination 
of  TERMINAL  (terminal  device),  LISTING  (listing  file),  DIAGNOSTICS 
(diagnostics  file).  The  message  categories  are  summarized  as  follows; 


WARNINGS 

WEAK.WARNINGS 


SUPPLEMENTAL 

COMPILATION.NOTES 


STATUS 


W-Ievel:  Indicates  a  definite  problem  in  a  legal 
program,  for  example,  an  unknown  pragma. 

1-level:  Indicates  a  potential  problem  in 
a  legal  program;  for  example,  a  possible 
CONSTRAINT.ERROR  at  run  time.  These 
are  the  only  kind  of  1-level  messages  that  are 
counted  in  the  summary  statistics  at  the  end  of 
a  compilation. 

1-level;  Additional  information  associated  with 
preceding  E-level  or  W-level  diagnostics. 

I-level:  Information  about  how  the  compiler 
translated  a  program,  such  as  record  layout, 
parameter-passing  mechanisms,  or  decisions 
made  for  the  pragmas  INLINE.  INTERFACE,  or 
the  import-subprogram  pragmas. 

I-level;  End  of  compilation  statistics  and  other 
messages. 


The  defaults  are  as  follows. 

/WARN I NGS- ( WARN : ALL , WEAK : ALL , SUPP : ALL , COMP : NONE , STAT : L I  ST  I 

Note  that  abbreviations  are  valid. 

If  you  specify  only  some  of  the  message  categories  with  the 
/WARNINGS  qualifier,  the  default  values  for  other  categories  are  used. 
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Examples 

1  3  XDADA  MODEL_:NTERFACE_,MODEI._:NTERrACE,CDNTROL_DCOP 

The  XDADA  command  compiles  the  compilation  units  con¬ 
tained  in  the  three  files  MODEL_INTERFACE_.ADA,  MODEL, 
INTERFACE.ADA,  and  CONTROL_LOOP.ADA,  in  the  order  given. 

2.  S  XDADA/LIST/SHOW-ALL  SCREEN, I 0_, SCREEN, 10 

The  XDADA  command  compiles  the  compilation  units  contained 
in  the  two  files  SCREEN,IO,.ADA  and  SCREEN,IO.ADA,  in  the 
order  given.  The  /LIST  qualifier  creates  the  listing  files  SCREEN, 
IO,.LIS  and  SCREEN,IO.LIS  in  the  current  default  directory.  The 
/SHOW- ALL  qualifier  causes  all  listing  file  options  to  be  provided 
in  the  listing  files. 
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LINKER  OPTIONS 

The  linker  options  of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the 
customer.  Unless  specifically  noted  otherwise,  references  in  this  appendix  are  to  linker  documentation 
and  not  to  this  report. 
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LINK 


Creates  an  executable  image  file  for  the  specified  units. 


Format 


LINK  unit-name  [fHe-spec[, . . .]] 
LINK/NOMAIN  unit-name[,...]  file-spec [,...] 


Command  Qualifiers 
/AFTER  =  time 
/BATCH.LOG  -  file-spec 
/BRIEF 

/COMMAND! » file-spec] 
/(NOjDEBUG 

/ELABORATION  >  file-spec 
/FULL 

/(NOjlMAGEI- file-spec) 
/(NOjKEEP 
/(NOILOG 
/(NOjMAIN 

/(NO|MAP(  -  file-spec] 

/NAME -job-name 

/(NOJNOTIFY 

/OUTPUT -file-spec 

/(NOjPR/NTERf «  queue-name] 

/OUEUE  -  queue-name 

/INOjSELECTIVE 

/SUBMIT 

/WAIT 


Defaults 

/AFTER -TODAY 
See  text. 

See  text. 

See  text. 

/NODEBUG 
See  text. 

See  text. 

/IMAGE 

/KEEP 

/NOLOG 

/MAIN 

/NOMAP 

See  text. 

/NOTIFY 

/OUTPUT  -  SYSSOUTPUT 

/NOPRINTER 

/QUEUE -SYSSBATCH 

/SELECTIVE 

/WAIT 

/WAIT 


Parameter  Qualifiers 

/LIBRARY 

/MAPPING 

/TARGET 


Defaults 
See  text. 
See  text. 
See  text. 
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Prompts 


Unit: 

File: 


Command  Parameters 

unit-name 

By  default  (or  if  you  specify  the  /MAIN  qualifier): 

•  You  can  specify  only  one  unit,  the  source  code  of  which  must  be 
written  in  XD  Ada. 

•  The  parameter  unit-name  specifies  the  XD  Ada  main  program,  which 
must  be  a  procedure  or  function  with  no  parameters.  If  the  main 
program  is  a  function,  it  must  return  a  value  of  a  discrete  type;  the 
function  value  is  used  as  the  VMS  image  exit  value. 

If  you  specify  the  /NOMAIN  qualifier: 

•  You  can  specify  one  or  more  foreign  units  that  are  to  be  included 
in  the  executable  image.  The  unit  names  may  include  percent  signs 
(%)  and  asterisks  (*)  as  wildcard  characters.  (See  the  VMS  DCL 
Concepts  Manual  for  detailed  information  on  wildcard  characters.) 

•  Fhe  image  transfer  address  comes  from  one  of  the  foreign  files 
specified. 

file-spec 

Specifies  a  list  of  object  files,  object  libraries,  mapping  definition  files, 
and  target  definition  files,  that  are  to  be  used  in  iiitking  the  program. 
The  default  directory  is  the  current  default  directory.  The  default  file 
type  is  .XOB,  unless  the  /LIBRARY,  /MAPPING,  or  /TARGET  qualifier  is 
used.  No  wildcard  characters  are  allowed  in  a  file  specification. 

If  the  file  is  an  object  library,  you  must  use  the  /LIBRARY  qualifier.  The 
default  file  type  is  XLB. 

If  the  file  is  a  mapping  definition  file,  you  must  use  the  /MAPPING 
qualifier.  The  default  file  type  is  .MPD. 

If  the  file  is  a  target  definition  file  you  must  use  the  /TARGET  qualifier. 
The  default  file  type  is  TGD. 

If  you  specify  the  /NOMAIN  qualifier,  the  image  transfer  address  comes 
from  one  of  the  files  (not  units)  specified. 
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Description 

The  LINK  cominand  performs  the  following  steps: 

1.  Runs  the  prebuild  phase  to  generate  an  elaboration  list. 

2.  Checks  if  a  pragma  LINK_OPTION  is  specified  for  the  main  pro¬ 
gram,  and  if  specified,  verifies  that  the  designated  link  option  name 
is  available  in  the  current  program  library.  If  available,  the  copied 
link  option  files  in  the  library  corresponding  to  the  lirdc  option  are 
used,  unless  overridden  by  the  /TARGET  or  /MAPPING  qualifiers. 

Note  that,  unlike  the  CHECK  command,  the  pragma  LINK_ 
OPTION  association  for  units  other  than  the  main  program  unit 
is  not  checked. 

If  no  target  link  option  is  given  for  the  main  program  unit  or  the 
designated  target  link  option  is  not  found  in  the  library,  and  the 
logical  name  XDADA$TARGET_DEF  is  not  defined,  and  a  /TARGET 
qualifier  is  not  specified  on  the  LINK  command  line,  an  error  is 
issued.  If  no  mapping  link  option  is  given  for  the  main -program  unit 
or  the  designated  mapping  link  option  is  not  found  in  the  library, 
and  the  logical  name  XDADA$MAPPING_DEF  is  not  defined,  and  a 
/MAPPING  qualifier  is  not  specified  on  the  XDACS  LINK  command 
line,  the  default  mapping  in  the  target  definition  file  is  used. 

3.  If  LINK/NOMAIN  is  not  specified,  checks  that  only  one  unit  is 
specified  and  that  it  is  an  XD  Ada  main  program. 

4.  Forms  the  closure  of  the  main  program  (UNK/MAIN)  or  of  the 
specified  units  (UNK/NOMAIN)  and  verifies  that  all  units  in  the 
closure  are  present,  current  and  complete.  If  XDACS  detects  an 
error,  the  operation  is  terminated  at  the  end  of  the  prebuild  phase. 

5.  Creates  a  DCL  command  file  for  the  builder.  The  command  file  is 
deleted  after  the  LINK  operation  is  completed  or  terminated,  unless 
UNK/COMMAND  is  specified.  If  UNK/COMMAND  is  specified, 
the  command  file  is  retained  for  future  use,  and  the  build  phase  is 
not  carried  out. 

6.  Unless  the  /COMMAND  qualifier  is  specified,  performs  the  build 
phase  as  follows: 

a.  By  default  (LINK/WAIT),  the  command  file  generated  in  step 
5  is  executed  in  a  subprocess.  You  must  wait  for  the  build 
operation  to  terminate  before  issuing  another  command.  Note 
that  when  you  specify  the  /WAIT  qualifier  (the  default),  process 
logical  names  are  propagated  to  the  subprocess  generated  to 
execute  the  command  file. 
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b.  If  you  specih'  the  -SUBMIT  qualifier,  the  builder  command  file 
IS  submitted  as  a  batch  job. 

7.  If  the  /DEBUG  qualifier  is  included  in  the  command  line  the  debug 
symbol  table  information  is  placed  in  the  XXE  file. 

8.  Creates  a  loadable  output  file  with  a  default  file  type  of  XXE. 

XDACS  output  originating  before  the  builder  is  invoked  is  reported 
to  your  terminal  by  default,  or  to  a  file  specified  with  the  /OUTPUT 
qualifier.  Diagnostics  are  reported  to  your  terminal,  by  default,  or  to 
a  log  file  if  the  LINK  command  is  executed  in  batch  mode  (XDACS 
UNK/SUBMIT). 

See  Developing  XD  Ada  Programs  on  VMS  Systems  for  the  MC68020  and  the 
XD  Ada  Version  1.2  New  Features  Manual  for  more  information  on  the  XD 
Ada  target-specific  builder  commands. 


Command  Qualifiers 

(AFTER  =  time 

Requests  that  the  batch  job  be  held  until  after  a  specific  hme.  when 
the  LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT).  If  the 
specified  time  has  already  passed,  the  job  is  queued  for  immediate 
processing. 

You  can  specify  either  an  absolute  time  or  a  combination  of  absolute 
and  delta  time.  See  the  VMS  DCL  Concepts  Manual  (or  type  HELP 
Specify  Date-Time  at  the  DCL  prompt)  for  complete  information  on 
specif^ng  time  values. 

/BATCH^LOQ  » file-spec 

Provides  a  file  specification  for  the  batch  log  file  when  the  LINK  com¬ 
mand  is  executed  in  batch  mode  (LINK/SUBMIT). 

If  you  do  not  give  a  directory  specification  with  the  file-spec  option,  the 
batch  log  file  is  created  by  default  in  the  current  default  directory.  If 
you  do  not  give  a  file  specification,  the  default  file  name  is  the  job  name 
specified  with  the  /NAME -job-name  qualifier.  If  no  job  name  has  been 
specified,  the  program  library  manager  creates  a  file  name  comprising 
up  to  the  first  39  characters  of  the  first  unit  name  specified.  If  you 
specified  LINK/NOMAlN  and  no  job  name  and  there  is  a  vv-ildcard 
character  in  the  first  unit  specified,  the  program  library  manager  uses 
the  default  file  name  XDACS.LINK.  The  default  file  type  is  LOG. 
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/BRIEF 

Directs  the  builder  to  produce  a  briet  image  map  file  The  -  BRIEF 
qualifier  is  valid  only  if  you  also  specif\’  the  /MAP  qualifier  uTth  the 
LINK  command.  The  /BRIEF  qualifier  is  incompatible  with  the  /FULL 
qualifier. 

A  brief  image  map  file  contains  only  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  LirUc  run  statistics 

See  also  the  description  of  the  /FULL  qualifier. 

/COMMAND[= file-spec] 

Controls  whether  the  builder  is  invoked  as  a  result  of  the  LINK  com¬ 
mand,  and  determines  whether  the  command  file  generated  to  invoke 
the  builder  is  saved.  If  you  specify  the  /COMMAND  qualifier,  XDACS 
does  not  invoke  the  builder,  and  the  generated  command  file  is  saved 
for  you  to  invoke  or  submit  as  a  batch  job. 

The  file-spec  option  allows  you  to  enter  a  file  specification  for  the  gen¬ 
erated  command  file.  The  default  directory  for  the  command  file  is  the 
current  default  directory.  By  default,  XDACS  provides  a  file  name  com¬ 
prising  up  to  the  first  39  characters  of  the  first  unit  name  specified.  If 
you  specified  LINK/NOMAIN  and  you  used  a  wildcard  character  in  the 
first  unit  name  specified,  the  program  library  manager  uses  the  default 
file  name  XDACS. LINK.  The  default  file  type  is  .COM.  No  wildcard 
characters  are  allowed  in  the  file  specification. 

By  default,  if  the  /COMMAND  qualifier  is  not  specified,  XDACS  deletes 
the  generated  command  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/DEBUG 
/NODEBUG  (D) 

Controls  whether  a  debugger  symbol  table  is  generated  in  the  loadable 
image  file. 

By  default,  no  debugger  symbol  table  is  created. 

/ELABORATION  =  file-spec 

Provides  a  file  specificahon  for  the  object  file  generated  by  the  LINK 
command.  The  file  is  retained  by  XDACS  only  when  the  /COMMAND 
qualifier  is  used:  that  is,  when  the  result  of  the  LINK  operation  is  to 
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produce  a  builder  command  tile  for  future  use.  rather  than  to  invoke  the 
builder  immediately. 

The  generated  object  tile  contains  the  code  that  directs  the  elaboration 
of  library  packages  in  the  closure  of  the  units  specified.  Unless  you  also 
specify  the  /NOMAIN  qualifier,  the  object  file  also  contains  the  image 
transfer  address. 

The  default  directory  for  the  generated  text  file  is  the  current  default 
directory.  The  default  file  type  is  .ELB.  No  wildcard  characters  are 
allowed  in  the  file  specification. 

By  default,  if  you  do  not  specify  the  /ELABORATION  qualifier,  XDACS 
provides  a  file  name  comprising  up  to  the  first  39  characters  of  the  first 
unit  name  specified. 

By  default,  if  you  do  not  specify  the  /COMMAND  qualifier,  XDACS 
deletes  the  generated  object  file  when  the  LINK  command  completes 
normally  or  is  terminated. 

/FULL 

Directs  the  builder  to  produce  a  full  image  map  file,  .vhich  is  the  most 
complete  image  map.  The  /FULL  qualifier  is  valid  only  if  you  also 
specify  the  /MAP  qualifier  with  the  LINK  command.  Also,  the  /FULL 
qualifier  is  incompatible  with  the  /BRIEF  qualifier. 

A  full  image  map  file  contains  the  following  sections: 

•  Object  module  information 

•  Segment  mapping  information 

•  Symbol  address  information 

•  Exception  numbers 

•  Link  run  statistics 

/IMAGE[=  file-spec]  (D) 

INOIMAGE 

Controls  whether  the  LINK  command  creates  a  loadable  image  file  and 
optionally  provides  a  file  specification  for  the  file.  The  default  file  type 
is  .XXE.  No  wildcard  characters  are  allowed  in  the  file  specification. 

By  default,  an  executable  image  file  is  created  with  a  file  name  compris¬ 
ing  up  to  the  first  39  characters  of  the  first  unit  name  specitied. 
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/KEEP  (D) 

INOKEEP 

Controls  whether  the  batch  log  tile  generated  is  deleted  after  it 
is  printed  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT). 

By  default,  the  log  file  is  not  deleted. 

/LOG 

/NOLOG  (D) 

Controls  whether  a  list  of  all  the  units  included  in  the  executable  image 
is  displayed.  The  display  shows  the  units  according  to  the  order  of 
elaboration  for  the  program. 

By  default,  a  list  of  all  the  units  included  in  the  executable  image  is  not 
displayed. 

/MAIN  (D) 

INOMAIN 

Controls  where  the  image  transfer  address  is  to  be  found.  _ 

The  /MAIN  qualifier  indicates  that  the  XD  Ada  unit  spccihed  deter¬ 
mines  the  image  transfer  address,  and  hence  is  to  be  a  main  program. 

The  /NOMAIN  qualifier  indicates  that  the  image  transfer  address  comes 
from  one  of  the  files  specified,  and  not  from  one  of  the  XD  Ada  units 
specified. 

By  default  (/MAIN),  only  one  XD  Ada  unit  can  be  specified,  and  that 
unit  must  be  an  XD  Ada  main  program. 

/MAPl»fll9‘Spec] 

/NOMAP  (D) 

Controls  whether  the  builder  creates  an  image  map  file  and  optionally 
provides  a  file  specification  for  the  file.  The  default  directory  for 
the  image  map  file  is  the  current  directory.  The  default  file  name 
comprises  up  to  the  first  39  characters  of  the  first  unit  name  specified. 
The  default  file  type  is  .MAP.  No  wildcard  characters  are  allowed  in  the 
file  specification. 

If  neither  the  /BRIEF  nor  the  /FULL  qualifier  is  specified  with  the  /MAP 
qualifier,  /BRIEF  is  assumed. 

By  default,  no  image  map  file  is  created. 
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/NAME = job-name 

Specifies  a  string  to  be  used  as  the  job  name  and  as  the  file  name  for 
the  batch  log  file  when  the  LINK  command  is  executed  in  batch  mode 
(LINK/SUBMIT).  The  job  name  can  have  from  1  to  39  characters. 

By  default,  if  you  do  not  specify  the  /NAME  qualifier,  XDACS  creates 
a  job  name  comprising  up  to  the  first  39  characters  of  the  first  unit 
name  specified.  If  you  specify  LINK/NOMAIN  but  do  not  specify  the 
/NAME  qualifier,  and  you  use  a  wildcard  character  in  the  first  uriit 
name  specified,  the  program  library  manager  uses  the  default  file  name 
XDACS_LINK.  In  these  cases,  the  job  name  is  also  the  file  name  of  the 
batch  log  file. 

/NOTIFY  (D) 

/NONOTIFY 

Controls  whether  a  message  is  broadcast  when  the  LINK  command  is 
executed  in  batch  mode  (UNK/SUBMIT).  The  message  is  broadcast  to 
any  terminal  at  which  you  are  logged  in,  notifying  you  that  your  job  has 
been  completed  or  termiiuted. 

By  default,  a  message  is  broadcast. 

/OUTPUT = file-spec 

Requests  that  any  output  generated  before  the  builder  is  invoked  be 
written  to  the  file  specified  rather  than  to  SYSSOUTPUT.  Any  diagnostic 
messages  are  written  to  both  SYSSOUTPUT  and  the  file. 

The  default  directory  is  the  current  default  directory.  If  you  specify  a 
file  type  but  omit  the  file  name,  the  default  file  name  is  XDACS.  The 
default  file  type  is  .LIS.  No  wildcard  characters  are  allowed  in  the  file 
specification. 

By  default,  the  LINK  command  output  is  written  to  SYSSOUTPUT. 

IPRINTER[  =  queue-name] 

/NOPRINTER  (D) 

Controls  whether  the  log  file  is  queued  for  printing  when  the  LINK 
command  is  executed  in  batch  mode  (LINK/SUBMIT)  and  the  batch  job 
is  completed. 

The  /PRINTER  qualifier  allows  you  to  specify  a  particular  print  queue. 
The  default  print  queue  for  the  log  file  is  SYSSPRINT. 

By  default,  the  log  file  is  not  queued  for  printing.  If  you  specify 
/NOPRINTER,  /KEEP  is  assumed. 
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/QUEUE  =  queue-name 

Specifies  the  batch  job  queue  in  which  the  job  is  entered  when  the 
LINK  command  is  executed  in  batch  mode  (LINK/SUBMIT). 

By  default,  if  the  /QUEUE  qualifier  is  not  specified,  the  job  is  placed  in 
the  default  system  batch  job  queue,  SYSSBATCH. 

/SELECTIVE  (D) 

INOSELECTIVE 

Specifies  whether  selective  linking  is  performed. 

Performing  selective  linking  ensures  that  only  subprograms  that  are 
called  will  be  liitked  into  the  program  image.  Subprograms  within  the 
closure  of  the  main  program  that  are  not  actually  called  will  be  omitted 
from  the  image  file.  Selective  linking  produces  a  program  image  that 
has  been  optimized  according  to  size. 

Non-selective  lirUcing  ensures  that  all  defined  subprograms  are  lirtked 
into  the  image. 

By  default,  selective  lirtking  is  performed.  _  . 

(SUBMIT 

Directs  XDACS  to  submit  the  command  file  generated  for  the  builder 
to  a  batch  queue.  You  can  continue  to  issue  commands  in  your  current 
process  without  waiting  for  the  batch  job  to  complete.  The  builder 
output  is  written  to  a  batch  log  file. 

By  default,  the  generated  command  file  is  executed  in  a  subprocess 
(UNK/WAIT). 

(WAIT 

Directs  XDACS  to  execute  the  command  file  generated  for  the  builder 
in  a  subprocess.  Execution  of  your  current  process  is  suspended  until 
the  subproccss  completes.  The  builder  output  is  written  directly  to 
your  terminal.  Note  that  process  logical  names  are  propagated  to  the 
subprocess  generated  to  execute  the  command  file. 

By  default,  XDACS  executes  the  command  file  generated  for  the  builder 
in  a  subprocess:  you  must  wait  for  the  subprocess  to  terminate  before 
you  can  issue  another  command. 
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Parameter  Qualifiers 

/LIBRARY 

Indicates  that  the  rtssociated  input  file  is  an  object  module  library  to  be 
searched  for  modules  to  resolve  any  undefined  symbols  in  the  input 
files.  The  default  file  type  is  XLB. 

By  default,  if  you  do  not  specify  the  /LIBRARY  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/MAPPING 

Indicates  that  the  associated  input  file  is  a  mapping  definition  file. 
Mapping  definition  files  control  the  location  of  the  program  on  the 
target  system.  The  default  file  type  is  .MPD. 

By  default,  if  you  do  not  specify  the  /MAPPING  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  type  of  .XOB. 

/TARGET 

Indicates  that  the  associated  input  file  is  a  target  definition  file.  Target 
definition  files  describe  the  target  system's  memory.  The  default  file 
type  is  .TGD. 

By  default,  if  you  do  not  specify  the  /TARGET  qualifier,  the  file  is 
assumed  to  be  an  object  file  with  a  default  file  ty^e  of  .XOB. 


Examples 

1  XDACS>  LINK  CONTROL_LOOP 

\ACS-I-CL_l:nkING,  invoking  th«  XD  Ada  Builder 

The  LINK  command  forms  the  closure  of  the  unit  CONTROL. 
LOOP,  which  is  an  XD  Ada  main  program,  creates  a  builder  com¬ 
mand  file  and  package  elaboration  file,  then  invokes  the  command 
file  in  a  spawned  subprocess. 

2.  XOACS>  LINK/SUBMIT  CCNTBOL.LOOP  LOOP.FUNCTIONS/LIBRARV 

\ACS-I-CL_SUBMITTED,  Job  CONTROL.LOOP  (queue  ALL.BATCH,  entry  134 ( 
started  on  FAST.BATCH 

The  LINK  command  instructs  the  builder  to  link  the  closure  of  the 
XD  Ada  main  program  CONTROL. LOOP  against  the  library  LOOP. 
FUNCTIONS. XLB.  The  /SUBMIT  qualifier  causes  XDACS  to  submit 
the  builder  command  file  as  a  batch  job. 
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The  LINK  command  builds  the  XD  Ada  units  FLLTD_VOLUME 
and  COUNTER  with  the  foreign  object  file  MONITOR  XOB.  The 
/NOMAIN  qualifier  tells  the  builder  that  the  image  transfer  address 
is  in  the  foreign  file. 


ArAcs>  1 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to  implementation-dependent  pragmas, 
to  certain  machine-dependent  conventions  as  mention^  in  Chapter  13  of  the  Ada  Standard,  and  to 
certain  allowed  restrictions  on  representation  clauses.  The  implementation-dependent  characteristics 
of  this  Ada  implementation,  as  described  in  this  Appendix,  are  provided  by  the  customer.  Unless 
specifically  noted  otherwise,  references  in  this  Appendix  are  to  compiler  documentation  and  not  to 
this  report.  Implementation-specific  portions  of  the  package  STANDARD,  which  are  not  a  part  of 
Appendix  F,  are: 


package  STANDARD  is 

type  INTEGER  is  range  -2147483648  ..  2147483647; 

type  SHORT_INTEGER  is  range  -32768  ..  32767; 

type  SHORT_SHORT_INTEGER  is  range  -128  ..  127; 

type  FLOAT  is  digits  6  range  -(2**128  -  2**104)  ..  2**128  -  2**104; 

type  LONG_FLOAT  is  digits  15  range  -(2**1024  -2**971)  ..  2**1024  -  2**971; 

type  LONG_LONG_FLOAT  is  digits  18  range  (-2**16384  -  2**16320)  ..  2**16384  -  2**16320; 

type  DURATION  is  delta  l.OE-4  range  -131072.0000  ..  131071.9999; 

end  STANDARD; 
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Chapter  1 

Introduction 


The  target  name  for  XD  Ada  MC68040  is  "MC68040’',  and  not 
"MC68020".  This  applies  throughout  the  manual. 
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Implementation-Dependent 

Characteristics 


F.3  Specification  of  Package  SYSTEM 

The  package  SYSTEM  for  the  MC68040  configuration  differs  from  that 
of  the  standard  MC68020  as  follows: 


F.3.1  Package  SYSTEM  for  the  MC68040  Target 

For  MC68040,  the  system  description  has  been  redefined  as  follows; 

typm  NAME  !■  (MC63040I; 

SYSTEM_NAME  !  eoBStut  NAME  :•  MCS904?: 

STORAoi.UNIT  !  coBBtaat  s-  9; 

MEMCRi  ilZE  !  eoaatBBt 
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NOTE 

This  appendix  is  not  part  of  the  standard  definition  of  the 
Ada  progranuning  language. 

This  appendix  summarizes  the  following  implementation-dependent 
characteristics  of  XD  Ada: 

•  Listing  the  XD  Ada  pragmas  and  attributes. 

•  Giving  the  specification  of  the  package  SYSTEM. 

•  Presenting  the  restrictions  on  representation  clauses  and  unchecked 
type  conversions. 

•  Giving  the  conventions  for  names  denoting  implementation- 
dependent  components  in  record  representation  clauses. 

•  Giving  the  interpretation  of  expressions  in  address  clauses. 

•  Presenting  the  implementation-dependent  characteristics  of  the 
input-output  packages. 

•  Presenting  other  implementation-dependent  characteristics. 

References  all  apply  to  sectiorts  in  the  XD  Ada  MC68020  Supplement  to 
the  Ada  Language  Reference  Manual. 
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F.1  Implementation-Dependent  Pragmas 

XD  Ada  provides  the  following  pragmas,  which  are  defined  elsewhere 
in  the  text.  In  addihon,  XD  Ada  restricts  the  predefined  language 
pragmas  INLINE  and  INTERFACE,  provides  pragma  VOLA'nLE  in 
addition  to  pragma  SHARED,  and  provides  pragma  SUPPRESS_ALL  in 
addition  to  pragma  SUPPRESS.  See  Annex  B  for  a  descriptive  pragma 
summary. 

•  CALL_SEQUENCE_FUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  EXPORT_EXCEPnON  (see  Section  13.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13. 9a.  1.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.l.2) 

•  IMPORT.EXCEPTION  (see  Section  13.9a. 3.1) 

•  IMPORT, FUNCTION  (see  Section  13.9a.  1.1) 

•  IMPORT.OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT_PROCEDURE  (see  Section  13. 9a.  1.1) 

•  LEVEL  (see  Section  13.5.1) 

•  LINK.OPTION  (see  Annex  B) 

•  SUPPRESS, ALL  (see  Section  11.7) 

•  TITLE  (see  Aitnex  B) 

•  VOLATILE  (see  Section  9.11) 


F.2  Implementation-Dependent  Attributes 

XD  Ada  provides  the  following  attributes,  which  are  defined  elsewhere 
in  the  text.  See  Appendix  A  for  a  descriptive  attribute  sunrunary. 

•  BIT  (see  Section  13.7.2) 

•  MACHINE,SIZE  (see  Section  13.7.2) 

•  TYPE,CLASS  (see  Section  13.7a.2) 
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F.3  Specification  of  the  Package  System 

The  package  SYSTEM  for  the  MC68020  is  as  follows: 

package  SYSTEM  la 

type  NAME  la  (MC66020); 

SYSTEM_NAME  :  eeaataat  NAME  MC68020; 

STORAaE_UNIT  I  eeaataat  8; 

MEM0RY_il2E  i  eeaataat  i-  2**31-1; 

MIN_INT  :  eeaataat  i-  -(2**31); 

MAX_INT  i  eeaataat  i-  2**31-1; 

MAX_DiaiTS  :  eeaataat  :•  18; 

MAX_MANTISSA  :  eeaataat  i-  31; 

FINE_OELTA  :  eeaataat  i-  2.0**(-31); 

TICK  :  eeaataat  <-  162.SE-6; 

aubtypa  PRIORITY  la  INTEGER  raage  0  ..  IS; 

aubtype  LEVEL  la  INTEGER  raage  0  ..  7; 

—  Addreaa  type 

type  ADDRESS  la  private; 

ADDRESS_ZERO  I  eeaataat  ADDRESS; 

type  ADDRESS_INT  la  raage  MIN_INT  ..  MAX_INT; 

fuaetlea  TO_ADDRESS  (X  >  ADDReSS_INT)  ratura  ADDRESS; 

(uaetlea  TO_ADORESS  (X  t  <univaraal_intagar} )  ratura  ADDRESS; 

fuaetlea  TO_ADDRESS_INT  (X  t  ADDRESS)  ~  ratura  AODRESS_INT; 

fuaetlea  (LEFT  :  ADDRESS;  RIGHT  :  ADDRESS_INT)  ratura  ADDRESS; 

fuaetlea  •*’  (LEFT  t  ADDRESS_INT;  RIGHT  i  ADDRESS^  ratura  ADDRESS; 

fuaetlea  '-*  (LEFT  i  ADDRESS;  RIGHT  :  ADDRESS)  ratura  ADDRESS_INT; 

fuaetlea  •-*  (LEFT  «  ADDRESS;  RIGHT  :  ADDRESS_INT)  ratura  ADDRESS? 

—  fuaetlea  *•*  (LEFT,  RIGHT  t  ADDRESS)  ratura  BOOLEAN; 

—  fuaetlea  ’/•*  (LEFT,  RIGHT  t  ADDRESS)  ratura  BOOLEAN; 

fuaetlea  ’<*  (LEFT,  RIGHT  i  ADDRESS)  ratura  BOOLEAN; 

fuaetlea  (LEFT,  RIGHT  i  ADDRESS)  ratura  BOOLEAN; 

fuaetlea  ’>’  (LEFT,  RIGHT  t  ADDRESS)  ratura  BOOLEAN; 

fuaetlea  '»*  (LEFT,  RIGHT  :  ADDRESS)  ratura  BOOLEAN; 

--  Note  that  becauae  ADDRESS  is  a  private  type 

—  the  functions  and  "/-*  are  already  available 

—  Generic  functions  used  to  access  memory 

gaaerle 

type  TARGET  la  private; 

fuaetlea  FETCH_FROM_ADORESS  (A  i  ADDRESS)  ratura  TARGET; 
gaaerle 

typo  TARGET  la  private; 

preeoduro  ASSiaN_TO_ADORESS  (A  i  ADDRESS;  T  i  TARGET); 
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ty|>«  TYPE_CLASS  im  ( TVPE_CLASS_ENUMERATICtl, 
type~class_:nteger, 
TYPB~CLASS_FIXED_POINT, 
TYPE"cLASS~FLOAT'iNG_POINT, 
T YPE_CLASS_ARaAY , 
TYPE_CLASS_RECCRD, 
TYPE~CLASS~ACCESS , 

type^class'task, 

TYPe”cLASS_ADDRESS)  ; 


XD  Ada  hardware-oriantad  typaa  and  functions 

typa  aiT^ARRAY  la  array  (INTEGER  raaga  <>)  of  BCX3LEAN; 
pragaa  PACK ( B I T_ARRAY ) ; 

subtypa  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7); 

subtypa  BIT~ARRAY~16  la  BIT_ARRAY  (0  ..  15); 

subtypa  BIT~ARRAy“32  la  BIt“aRRAY  (0  ..  31); 

subtypa  BIT~ARRAY~64  la  BIT^ARRAY  (0  ..  63); 

typa  UNSIGNiD_BYTi  la  raaga  0  ..  255; 
far  UNSIGNBO~BYTB'SIZB  uaa  8; 

fuaetlea  "not-  (LEFT  s  UNSIGNED_BYTB)  ratura  UNSIGNED_BYTE; 

fuaetloa  "and"  (LEFT,  RIGHT  t  UNS1GNED~BYTE)  ratura  UNSIGNED_BYTE; 

fuaetloa  ’or*  (LEFT,  RIGHT  «  UMSIGNE0~BYTB)  ratura  UNS1GNED_BYTE; 

fuaetlea  "xor*  (LEFT,  RIGHT  i  UNS1GNB0~BYTE)  ratura  UNSIGNBD_BYTE^  •. 

fuaetlea  TO_UNSIGNED_BYTE  (X  :  BIT_ARRAY_8)  ratura  UNSIGNED_BYTE; 
fuaetlea  T0~BIT_ARRAY_8  (X  i  UNSIGNED_BYTE)  ratura  BIT_ARRAY_8; 

typa  UNSIGNED_ByTE_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED_BYTE; 

typa  UNSIGNBO_WORO  la  raaga  0  ..  65535; 
for  UNSIGNED~WORO‘SIZB  usa  16; 

fuaetlea  ‘not’  (LEFT  i  UNSIGNED_W0R15)  ratura  UNSIGNED_WORD: 

fuaetlea  'and'  (LEFT,  RIGHT  s  UNSIGNBD~W0RD)  ratura  UNSIGNEC_WORD; 
fuaetlea  *or*  (LEFT,  RIGHT  i  UNSIGNED^WORD)  ratura  UNS1GNED_WORO; 
fuaetlea  "xor"  (LEFT,  RIGHT  i  UNSIGNED~W0RD)  ratura  UNSIONED_NORD; 

fuaetlea  TO_UNSIGNED_WORD  (X  i  arT_ARRAy_16)  ratura  UNSIGSeD_WORD; 
fuaetlea  To“biT_ARRAY_16  (X  i  UNSIGNED_HORD)  return  BIT_ARRAY_16 ; 

typa  UNSIGNED_W0R0_ARRAY  la  array  (INTEGER  raaga  <>)  ef  UNSIGNED_WORD; 


typa  UNSIGNED_L0NGW0R0  la  raaga  mN_INT  ..  MAX_INT: 
for  UNSIGNFD_LONGHORD'SIZE  use  32; 

fuaetlea  "not"  (LEFT  :  UNSIGNED_LONGWORD)  ratura  UNSIGNED_LONGWORD; 

fuaetlea  "and"  (LEFT,  RIGHT  :  UNSIGNBd”lONGWORD)  ratura  UNSIGNE0_L0NGH0RD; 

fuaetlea  'or'  (LEFT,  RIGHT  :  UNSIGNED~LONGWORD)  ratura  UNSIGNED_LONGWORD; 

fuaetlea  'xor'  (LEFT,  RIGHT  :  UNSIGNEd'lONGWORD)  return  UNSIGNED_LONGWORD; 

fuaetlea  T0_UNSIGNED_L0NGW0R0  (X  :  BIT_ARRAY_32 )  ratura  UNSIGNED_LONGHORD; 
fuaetlea  T0”bIT_ARRAY_32  (X  :  UNSIGNiD_WORD)  ratura  BIT_ARRAY_32 ; 

typa  UNSIGNED_LONGWORD_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED_L0NGH0R0; 
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Conventional  names  ! 

ior 

•ubtyp* 

UNSIGNED, 

Is 

subtyp* 

UNSIGNED^ 

2 

is 

•ubtyp* 

unsigned" 

3 

is 

subtype 

unsigned" 

4 

is 

subtype 

uNSi  :d3 

5 

is 

subtype 

unsigned" 

6 

is 

subtype 

unsigned" 

7 

is 

subtype 

unsigned” 

3 

is 

subtype 

unsigned" 

9 

is 

subtype 

unsigned^ 

10 

is 

subtype 

UNSIGNED^ 

11 

is 

subtype 

unsigned" 

12 

is 

subtype 

unsigned" 

13 

is 

subtype 

unsigned" 

14 

is 

subtype 

unsigned^ 

15 

is 

subtype 

unsigned" 

16 

is 

subtype 

unsigned^ 

17 

is 

subtype 

unsigned" 

18 

is 

subtype 

unsigned" 

19 

is 

subtype 

unsigned" 

20 

is 

subtype 

unsigned" 

21 

is 

subtype 

unsigned^ 

22 

is 

subtype 

unsigned" 

23 

is 

subtype 

unsigned^ 

24 

is 

subtype 

unsigned" 

25 

is 

subtype 

unsigned" 

26 

is 

subtype 

UNSIGNED^ 

27 

is 

subtype 

unsigned’ 

28 

is 

subtype 

unsigned’ 

29 

is 

subtype 

unsigned^ 

30 

is 

subtype 

UNSIGNED^ 

31 

is 

privat* 

—  Not  shown 
•ad  SYSTEM; 


static  suDtypes  c£  type  L;rJS:3NED_:.CN3WC:RD 


UNS I GNED_LONaWORD 

unsigned”longword 

unsigned”longword 

UNS I GNED~LCNGWORD 
UN  S I GNED^LONGWORD 
UNSIGNED~LONGWORD 

UNS I gnbd'lcngword 

UNS IGNED^LONGWORD 
UNS IGNED~LONGWORD 
UNS IGNED~LONGWORD 
UNSIGNED~LONGWORD 
UNSIGNEO~LONGWORD 
UNS I GNED~LONGWORD 
uns:gned~longword 
unsigneo^longword 
unsigned~longword 

UNS I GNED~LONGWORD 
UNS  I  GNED~LONGVIORD 
UNS I GNED^LONGWORD 
UNS I GNED^LONGWORD 
UNS I GNEO~LONGWORD 
UNS IGNED~LONGHORD 
UNSIGNED~LONGWORD 

UNS I gned'longword 
UNS I GNED^tONGWORD 
unsigned'longword 
UNS I GNED^LONGWORD 
UNSIGNED^LONGWORD 

UNS igned'longword 

UNSIGNED~LONGWORD 

UNSIGNED~LONGWORD 


rang* 

0  .  . 

2**  1-1 

rang* 

c  .  . 

2**  2-1 

raaga 

0  .  . 

2*. 

raaga 

0  .  . 

2"  ■  : 

raaga 

0  .  . 

2**  5-1 

raaga 

0  .  . 

2**  6-1 

raaga 

0  .  . 

:♦*  ■’-1 

raaga 

0  .  . 

2**  8-1 

raaga 

0  .  . 

2**  9-’ 

raaga 

0 

raaga 

0  .  . 

2*»11-1 

raaga 

0  .  . 

2**12-1 

raaga 

0  .  . 

2**13-1 

raaga 

0  .  . 

2**14-1 

raaga 

0  .  . 

2**15-1 

raaga 

0  .  . 

2**16-1 

raaga 

0  .  . 

2*»17-1 

raaga 

0  .  . 

2**18-1 

raaga 

0  .  . 

2««19-1 

raaga 

0  .  . 

2**20-l 

raaga 

0  .. 

2**21-1 

raaga 

0  .  . 

2**22-l 

raaga 

0  .  . 

2**23-l 

raaga 

0  .  . 

2**24-l 

raaga 

0  .. 

2**25-l 

raaga 

0  .  . 

2**26-l 

raaga 

0  .  . 

2»*27-l 

raaga 

0  .  . 

2**2e-l 

raaga 

0  .  . 

2**29-l 

raaga 

0  .  . 

2**30-l 

raaga 

0  .  . 

2**31-1 

F.4  Restrictions  on  Representation  Clauses 

The  representation  clauses  allowed  in  XD  Ada  are  length,  enumeration, 
record  representation,  and  address  clauses. 

In  XD  Ada,  a  representation  clause  for  a  generic  formal  type  or  a  type 
that  depends  on  a  generic  formal  type  is  not  allowed.  In  addition,  a 
representation  clause  for  a  composite  type  that  has  a  component  or 
subcomponent  of  a  generic  formal  type  or  a  type  derived  from  a  generic 
formal  t^e  is  not  allowed. 
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Restrictions  on  length  clauses  are  specified  in  Section  13.2,  restrictions 
on  enumeration  representation  clauses  are  specified  in  Section  13.3;  and 
restrictions  on  record  representation  clauses  are  specified  in  Section 
13.4. 


F.5  Conventions  for  Implementation-Generated  Names 
Denoting  Implementation-Dependent  Components  in 
Record  Representation  Clauses 

XD  Ada  does  not  allocate  implementation-dependent  components  in 
records. 


F.6  interpretation  of  Expressions  Appearing  in  Address 
Clauses 

Expressions  appearing  in  address  clauses  must  be  of  the  type  ADDRESS 
defined  in  paduige  SYSTEM  (see  Section  13.7a.  1  and  Section  F.3). 

XD  Ada  allows  address  clauses  for  variables  (see  Section  13.5).  For 
address  clauses  on  variables,  the  address  expression  is  interpreted  as  a 
Motorola  full  32-bit  address. 

XD  Ada  supports  address  clauses  on  task  entries  to  allow  interrupts  to 
cause  a  reschedule  directly.  For  address  clauses  on  task  entries,  the 
address  expression  is  interpreted  as  a  Motorola  exception  vector  offset. 

In  XD  Ada  for  MC68020,  values  of  type  SYSTEM. ADDRESS  are  inter¬ 
preted  as  integers  in  the  range  0  ..  2^^  -1.  As  SYSTEM.ADDRESS  is 
a  private  type,  the  only  operations  allowed  on  objects  of  this  type  are 
those  given  in  package  SYSTEM. 


F.7  Restrictions  on  Unchecked  Type  Conversions 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  restrictions  given  in  Section  10.3.2. 
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F.8  Implementation-Dependent  Characteristics  of 
Input-Output  Packages 

The  packages  SEQUENTIAL.IO  and  DIRECT_IO  are  implemented  as 
null  packages  that  conform  to  the  specification  given  in  the  Reference 
Manual  for  the  Ada  Programming  Language.  The  packages  raise  the  ex¬ 
ceptions  specified  in  Chapter  14  of  the  Reference  Manual  for  the  Ada 
Programming  Language.  The  three  possible  exceptions  that  are  raised  by 
these  packages  are  given  here,  in  the  order  in  which  they  are  raised. 


Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  upon  or  dose  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

USE.ERROR 

Raised  if  exception  STATUS.ERROR  is  not  raised. 

MODE. ERROR  cannot  be  raised  since  no  file  can  be  opened  (therefore 
it  cannot  have  a  current  mode). 

The  predefined  package  L0W_LEVEL_10  is  not  provided. 


F.8.1  The  Package  TEXTJO 

The  package  TEXT.IO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  String  input- 
output  is  implemented  as  defined.  File  input-output  is  supported  to 
STANDARD.INPUT  and  STAND ARD.OUT7UT  only.  The  possible 
exceptions  that  are  raised  by  package  TEXT.IO  are  as  follows: 
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Exception 

When  Raised 

STATUS.ERROR 

Raised  by  an  attempt  to  operate  ufxin  or  dose  a  file 
that  is  not  open  (no  files  can  be  opened). 

NAME.ERROR 

Raised  if  a  file  name  is  given  with  a  call  of  CREATE 
or  OPEN. 

MODE.ERROR 

Raised  by  an  attempt  to  read  from,  or  test  for 
the  end  of,  STANDARD.OUTPUT,  or  to  write  to 
STANDARD.INPUT. 

END.ERROR 

Raised  by  an  attempt  to  read  past  the  end  of 
STANDARD.INPUT. 

USE.ERROR 

Raised  when  an  unsupported  operation  is  attempted, 
that  would  otherwise  legal. 

The  type  COUNT  is  defined  as  follows: 

typ«  COUNT  la  raaga  0  ..  INTEGER' LAST; 

The  subtype  FIELD  is  defined  as  follows: 

typa  FIELD  la  INTEGER  raaga  0  ..  132; 


F.8.2  The  Package  IO_EXCEPTIONS 

The  specification  of  the  package  IO_ EXCEPTIONS  is  the  same  as  that 
given  in  the  Reference  Manual  for  the  Ada  Programming  Language. 


F.9  Other  Implementation  Characteristics 

Implementation  characteristics  associated  with  the  definition  of  a  main 
program,  various  numeric  ranges,  and  implementation  limits  are  sum¬ 
marized  in  the  following  sections. 


F.9.1  Definition  of  a  Main  Program 

Any  library  procedure  can  be  used  as  a  main  program  provided  that  it 
has  no  formal  parameters. 
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F.9.2  Values  of  Integer  Attributes 

The  ranges  of  values  for  integer  types  declared  in  package  STANDARD 
are  as  follows: 


short.short.integer 

-2'  .. 

2'  -1 

(-128  . 

.  127) 

SHORT.INTEGER 

-2‘’  . 

.  2'^  -1 

(-32768  . 

.  32767) 

INTEGER 

-2^'  . 

.  2^'  -1 

(-2147483648  . 

.  2147483647) 

For  the  package  TEXT_IO,  the  range  of  values  for  types  COUNT  and 
FIELD  are  as  follows: 

COUNT  0..  2^'  -1  (0..  2147483647) 

FIELD  0  ..  132 


F.9.3  Values  of  Floating-Point  Attributes 

Floating-point  types  are  described  in  Section  3.5.7.  The  representation 
attributes  of  floating-point  types  are  summarized  in  the  following  table: 
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FLOAT 

LONG.FLOAT 

LONG.LONG.FLOAT 

DIGITS 

6 

15 

18 

SIZE 

32 

64 

96 

MANTISSA 

21 

51 

61 

EMAX 

84 

204 

244 

EPSILON 

2-20 

2-so 

2-«® 

SMALL 

2-m 

2-20S 

2-245 

lARGE 

2M_2»3 

2204  _  2 133 

22U_2l»3 

SAFE.EMAX 

125 

1021 

16382 

SAFE.SMALL 

2*126 

2-1022 

2-1*383 

SAFE.LARGE 

2l25_2l(>* 

21021  _2«o 

2l»382  _2l*321 

RRST 

-(2'“-2'«) 

LAST 

2l024_2Wl 

21*384  _2l»320 

MACHINE.RADIX 

2 

2 

2 

MACHINE.MANTISSA 

24 

53 

64 

MACHINE.EMAX 

128 

1024 

16384  “  '• 

MACHINE.EMIN 

-125 

-1021 

-16382 

MACHINE.ROUNDS 

FALSE 

FALSE 

FALSE 

MACHINE.OVERFLOWS 

FALSE 

FALSE 

FALSE 
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F.9.4  Attributes  of  Type  DURATION 


The  values  of  the  significant  attributes  of  type  DURATION  are  as 
follows: 


DURATION 'DELTA 
DURATION 'SMALL 
DURATION 'FIRST 
DURATION 'LAST 


l.E-4 

l/Kl.O^E-H 

-131072.0000 

131071.9999 


(10-*) 

(2-'^ 

(-2'") 

(2‘U' DELTA) 


F.9.5  Implementation  Limits 


Limit 

255 

255 

210 

2'^ 

2“  -1 

2“  -1 
2»  -1 
2“  -1 


Description 

Maximum  identifier  length  (number  of  characters) 

Maximum  number  of  characters  in  a  source  line 

Maximum  number  of  library  units  and  subunits  in  a  compilation 
closure' 

Maximum  number  of  library  units  and  subunits  in  an  execution 
closure^ 

Maximum  number  of  enumeration  literals  in  an  enumeration 
type  definition 

Maximum  number  of  lines  in  a  source  file 
Maximum  number  of  bits  in  any  object 
Maximum  number  of  exceptions 


'The  compilation  closure  of  a  given  unit  is  the  total  set  of  units  that  the  given  unit 
depends  on,  directly  and  indirectly. 


^The  execution  closure  of  a  given  unit  is  the  compilation  closure  plus  all  associated 
secondary  units. 
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Appendix  F 

Implementation-Dependent 

Characteristics 


This  appendix  describes  Version  1.2  additions  to  the  range  of 
implementation-dependent  pragmas,  and  enhancements  to  the  func¬ 
tionality  of  Package  TEXT_IO.  It  supplements  information  supplied  in 
the  Version  1.0  version  of  this  appendix. 


F.1  Implementation-Dependent  Pragmas 

XD  Ada  MC68020  Version  1.2  supplies  three  new  pragmas,  DIRECT. 
INTERRUPT.ENTRY,  IDENT  and  uME.SLICE.  In  the  following  full 
list  of  supported  pragmas,  references  refer  to  sections  in  the  XD  Ada 
MC68020  Supplement  to  the  Ada  Language  Reference  Manual,  unless  updated 
by  sections  supplied  in  this  nnanual. 

•  CALL.SEQUENCE.FUNCnON  (see  Annex  B) 

•  CALL.SEQUENCE.PROCEDURE  (see  Annex  B) 

•  DIRECT.INTERRUPT.ENTRY  (see  Section  13.5.1) 

•  EXPORT.EXCEPTION  (see  Section  I3.9a.3.2) 

•  EXPORT.FUNCnON  (see  Section  13.9a.  1.2) 

•  EXPORT.OBJECT  (see  Section  13.9a.2.2) 

•  EXPORT.PROCEDURE  (see  Section  13.9a.l.2) 

•  IDENT  (see  Annex  B) 

•  IMPORT.EXCEPTION  (see  Section  I3.9a.3.1) 

•  IMPORT.FUNCnON  (see  Section  13.9a.l.l) 
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•  IMPORT.OBJECT  (see  Section  13.9a.2.1) 

•  IMPORT.PROCEDURE  (see  Section  13. 9a. 1.1) 

•  LEVEL  (see  Section  13.5.1) 

•  UNK.OPTION  (see  Annex  B) 

•  SUPPRESS.ALL  (see  Section  11.7) 

•  TITLE  (see  Annex  B) 

•  TIME.SUCE  (see  Section  9.8a) 

•  VOLATILE  (see  Section  9.11) 


F.8.1  The  Package  TEXTJO 

The  package  TEXT_IO  conforms  to  the  specification  given  in  the 
Reference  Manual  for  the  Ada  Programming  Language.  Package  TEXT.IO,  as 
supplied  by  XD  Ada  MC68020  Version  1.2,  has  changed  as  follows: 

•  The  Run-Time  System  now  supports  asynchronous  input-output 
operations,  where  a  TEXT.IO  operation  will  cause  only  the  task 
that  performs  the  operation  to  be  suspended  awaiting  its  com¬ 
pletion,  rather  than  all  the  tasks  in  the  program.  You  enable  this 
facility  by  compiling  the  file  XDADA$TARGET_SOURCE;ASYNC_ 
TERMINAL.IO.ADA  into  your  program  library,  as  described  in 
the  XD  Ada  MC68020  Version  1.2  New  Features  Manual.  You  dis¬ 
able  asynchronous  TEXT  lO  derations  by  compiling  the  file 
XDADA$TARGET.S0URC:E:TERMINAL_I0.ADA  into  your  pro¬ 
gram  library. 

•  Support  is  provided  for  target  input-output  to  be  directed  to  logical 
input  and  output  streams  on  the  host.  This  facility  is  available  for 
both  the  XDDEBUG  and  XDRUN  commands. 

Input  and  output  are  buffered.  For  input,  all  characters  up  to  an 
end  of  line  or  end  of  page  are  made  available  to  the  target  program 
before  further  characters  are  read.  For  output,  the  buffer  is  flushed 
following  an  end  of  line  or  end  of  page.  See  the  XD  Ada  MC68020 
Version  1.2  New  Features  Manual  for  details  of  the  TEXT.IO  data 
objects  that  control  this  behavior. 

Note  that  if  XDADASINPUT  and  XDADASOUTPUT  are  defined  but 
opening  the  file  gives  an  error,  for  example  the  file  does  not  exist, 
the  filename  is  invalid  or  no  read/write  permission  is  assigned,  the 
file  is  treated  as  empty. 
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Chapter  13 
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The  text  in  this  chapter  lists  the  differences  behveen  XD  Ada  MC68040 
and  XD  Ada  MC68020,  as  described  in  the  XD  Aiia  MC68020  Supplement 
to  the  Ada  Language  Reference  Manual. 


13.7  The  Package  SYSTEM 

The  following  information  replaces  the  MC68020  supplement  to  para¬ 
graph  5: 

In  XD  Ada  MC68040,  the  enumeration  literal  for  SYSTEM.NAME  is 
MC68040. 


13.7  tho  Package  SYSTEM 
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Supplementary  XD  Ada  information  is  provided  for  Sections  13.1,  13.2, 
13.3,  13.4,  13.5,  13.5.1,  13.7,  13.7.1,  13.7.2,  13.7.3,  13.8,  13.9,  13.10.1 
and  13.10.2.  Two  additional  sections.  Section  13.7a  and  Section  13.9a, 
provide  XD  Ada  information  on  the  package  SYSTEM  and  on  the  XD 
Ada  import  and  export  pragmas. 


13.1  Representation  Clauses 

The  following  information  supplements  paragraphs  4  and  8: 

In  XD  Ada,  an  address  clause  can  only  apply  to  a  variable  or  a  single 
entry;  an  address  clause  cannot  apply  to  a  constant,  subprogram, 
package,  or  task  unit.  See  Section  13.5  for  further  explanation. 

The  following  information  supplements  paragraph  13: 

Pragma  PACK  is  implemented  in  XD  Ada.  As  the  behavior  of  pragma 
PACK  is  implementation  dependent,  users  are  advised  to  use  represen¬ 
tation  clauses  to  ensure  a  particular  representation  across  targets. 

In  XD  Ada,  all  array  and  record  components  are  aligned  on  byte 
boundaries  by  default;  the  effect  of  pragma  PACK  on  a  record  or 
array  is  to  cause  those  components  that  are  packable  to  be  allocated  in 
adjacent  bits  without  regard  to  byte  boundaries.  Whether  any  particular 
component  is  packable  depends  on  the  rules  for  its  type;  the  XD 
Ada  MC68020  Run-Time  Reference  Manual  gives  information  on  which 
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ty'pes  can  be  packed  as  components  of  composite  types,  as  well  as 
information  on  how  these  types  are  packed. 

A  record  component  that  begins  a  variant  is  always  allocated  at  the  next 
byte  boundary;  a  variant  that  begins  on  other  than  a  byte  boundary  can 
be  obtained  only  with  a  record  representation  clause. 

XD  Ada  provides  no  additional  representation  pragmas. 

The  following  information  supplements  paragraph  14: 

XD  Ada  does  not  allow  a  representation  clause  for  a  type  that  depends 
on  a  generic  formal  type.  A  type  depends  on  a  generic  formal  type 
if  it  has  a  subcomponent  of  a  generic  formal  type  or  a  subcomponent 
that  depends  on  a  generic  formal  type,  or  if  it  is  derived  from  a  generic 
formal  type  or  a  type  that  depends  on  a  generic  formal  type. 


13.2  Length  Clauses 

The  following  information  supplements  paragraph  6: 

In  XD  Ada,  for  a  discrete  type,  the  given  si^e  must  not  exceed  32 
(bits).  The  given  size  becomes  the  default  allocation  for  all  objects  and 
components  (in  arrays  and  records)  of  that  type.  However,  sizes  of 
objects  may  be  increased  by  the  compiler  for  optimization  purposes. 

For  integer  and  enumeration  types,  the  given  size  affects  the  internal 
representation  as  follows:  for  integer  types,  high  order  bits  are  sign* 
extended;  for  enumeration  types,  the  high  order  bits  may  be  either 
zero-  or  sign-extended  depending  upon  the  base  representation  that 
is  selected.  For  all  other  types,  the  given  size  must  equal  the  size  that 
would  apply  in  the  absence  of  a  size  specification. 

The  following  information  supplements  paragraph  8: 

The  specification  of  a  collection  size  is  interpreted  as  follows.  If  the 
value  of  the  expression  is  greater  than  or  equal  to  zero,  the  specified 
size  (representing  the  number  of  bytes  in  the  collection)  is  rounded  up 
to  the  longword  boundary  nearest  (4  bytes),  and  is  then  used  as  the 
initial  size  of  the  collection;  the  collection  is  not  extended  should  that 
initial  allocation  be  exhausted.  In  the  absence  of  a  T' STORAGE. SIZE, 
no  storage  is  initially  allocated  for  the  collection;  storage  is  allocated 
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from  the  heap  as  needed,  until  all  heap  memory  is  exhausted.  If  the 
value  is  less  than  zero,  the  exception  CONSTRAINT.ERROR  is  raised. 

The  following  information  supplements  paragraph  10: 

A  task  storage  specification  overrides  the  default  task  storage  size.  The 
specification  is  interpreted  as  follows.  If  the  value  of  the  expression 
is  greater  than  zero,  the  specified  size  is  rounded  up  to  the  nearest 
longword  boundary  (4  bytes),  and  this  determines  the  number  of 
storage  units  (bytes)  to  be  allocated  for  an  activation  of  the  task  of  the 
given  type.  In  the  absence  of  a  T'STORAGE.SIZE,  a  default  all'-^cation 
is  used.  If  the  value  is  less  than  zero,  the  exception  CONSTRAINT. 
ERROR  is  raised. 

The  following  information  supplements  paragraphs  8  and  10: 

NOTE 

The  XD  Ada  MC68020  Run-Time  Reference  Manual  discusses 
task  and  access  type  storage  and  storage  allocation  in  more 
detail. 

The  following  information  supplements  paragraph  12:  -  - 

In  XD  Ada,  arbitrary  values  of  small  are  accepted.  The  default  value  of 
small  is  the  largest  power  of  two  that  is  not  greater  than  the  given  delta 
(see  Section  3.5.9). 

If  small  is  specified  (see  Section  3.5.9  (LRM)),  the  specified  value  must 
not  exceed  the  default.  For  example: 

(or  MY.FIXEO' SMALL  UM  0.001; 

This  example  is  a  legal  specification  for  the  declaration  of  MY.FIXED 
because  the  value  specified  for  small  (0.001)  is  less  than  the  delta  (0.1) 
and  that  also  satisfies  the  specified  range  (0.0..  1.0). 


13.3  Enumeration  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

In  XD  Ada,  the  only  specific  restriction  on  enumeration  representation 
clauses  is  that  each  expression  for  an  integer  code  must  have  a  value  in 
the  range  MIN.INT  ..  MAX.INT. 
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13.4  Record  Representation  Clauses 

The  following  information  supplements  paragraph  4: 

For  statically  allocated  objects  and  for  objects  allocated  from  a  collection 
in  XD  Ada,  the  simple  expression  in  an  alignment  clause  must  be 
a  power  of  two.  The  upper  limit  is  The  alignment  then  occurs 
at  a  location  that  is  a  number  of  bytes  times  the  value  of  the  simple 
expression:  a  value  of  2  causes  word  alignment,  a  value  of  4  causes 
longword  alignment,  and  so  on. 

Further  restrictions  apply  for  objects  declared  within  a  subprogram, 
where  XD  Ada  restricts  the  alignment  to  mod  1.  In  other  words,  stack- 
allocated  objects  can  only  be  byte  aligned. 

Bit-alignable  representation  clauses  are  provided  for  discrete  types, 
arrays  of  discrete  types,  and  record  types. 

See  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  information  on 
how  objects  are  allocated. 

The  following  information  supplements  paragraph  5: 

A  component  clause  specifies  the  storage  place  of  a  component  relative 
to  the  start  of  the  record.  In  XD  Ada  for  MC68020  targets,  the  size  of  a 
storage  unit  (SYSTEM.STORAGE.UNIT)  is  eight  bits  (one  byte).  If  the 
number  of  bits  specified  by  the  range  is  sufficient  for  the  component 
subtype,  the  requested  size  and  placement  of  the  field  is  observed  (and 
overlaps  storage  boundaries  if  necessary);  otherwise,  the  specification  is 
illegal.  For  a  component  of  a  discrete  type,  the  number  of  bits  must  not 
exceed  32;  for  a  component  of  any  other  type,  the  size  must  not  exceed 
the  actual  size  of  the  component.  See  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  for  information  about  determining  the  number  of  bits 
that  are  sufficient  for  any  given  subtype. 

Component  values  in  XD  Ada  are  biased  when  a  component  clause 
requires  a  very  small  component  storage  space;  each  value  stored 
is  the  unsigned  quantity  formed  by  subtracting  COMPONENT. 
SUBTYPE '  FIRST  from  the  original  value.  See  the  XD  Ada  MC68020 
Run-Time  Reference  Manual  for  more  detailed  information. 

Component  clauses  in  XD  Ada  are  restricted  as  follows.  Any  com¬ 
ponent  that  is  not  packable  must  be  allocated  on  a  byte  boundary. 
Components  that  are  packable  can  be  allocated  without  restriction.  See 
the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  a  deBnition  and 
description  of  packable  components. 
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The  following  information  supplements  paragraph  6: 

Components  named  in  a  component  clause  are  allocated  first;  then, 
unnamed  components  are  allocated  in  the  order  in  which  they  are 
written  in  the  record  type  declaration.  Variants  can  be  overlapped.  If 
pragma  PACK  is  specified,  packed  allocation  rules  (see  Section  13.1) 
are  used;  otherwise,  unpacked  allocation  is  used. 

The  following  information  supplements  paragraph  8: 

XD  Ada  generates  no  implementation-dependent  components  or 
names. 

The  following  information  supplements  the  Notes  section: 

The  example  of  record  representation  and  address  clauses  in  the 
Reference  Manual  for  tne  Ada  Programming  Language  is  not  relevant  for 
XD  Ada  as  it  assumes  that  t3T3e  ADDRESS  is  represented  in  24  bits, 
whereas  in  XD  Ada  type  ADDRESS  is  represented  in  32  bits.  The 
following  example  is  appropriate  to  XD  Ada: 

ExampI*: 

t7p*  CONDITION_CODE  la  (  X, N,  2 ,  V,  C ) ;  - 

typa  CONDITION_CODES  la  array  ( CONDITION_CODE )  of  BOOLEAN? 
pragaa  PACK  (CONDITION_CODES) ; 

typa  PROGRAM_STATUS_WORD  la 

racers 


TRACE_ENABLE 

:  INTEGER  raage 

0  . 

.  3; 

SUPERVI SOR_STATE 

1  BOOLEAN; 

INTERRUPT_STATE 

:  BOOLEAN; 

interrupt'mask 

:  INTEGER  raage 

0  . 

.  7; 

CC 

«  CONDITION_CODES; 

end  recerS; 

far  PROGRA«_STATUS_WORD  uaa 
record  at  mod  1; 

TRACe_ENABLE  at  0  raaya  0 

SUPERVISOR_STATe  at  0  raage  2 

INTERRUPT_iTATB  at  0  raage  3 

INTERRUPt'mASK  at  0  range  S 

CC  at  0  raage  11 

aad  record; 

for  PROGRAM_STAIUS_WORO'SIZE  uao  2  *  SYSTEM. STORAGE_UN IT; 

Not#  on  tha  axampla: 

The  record  representation  clause  defines  the  record  layout.  The  length 
clause  guarantees  that  exactly  two  storage  units  are  used. 


..  1: 
..  2; 

■  ■  3; 

..  7; 
..  15; 
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Component  Specification  Example; 


•ubtypa  S  la  INTEGER  raaga  10 

tyiM  REC  la 
raeord 
X  :  S; 

Y  :  S; 
aad  raeord; 


for  REC  uaa 
raeord 

X  at  0  raa^a  0  . .  3 ; 


Y  at  0  raaga  4  .  .  4 ; 


and  raeord; 


13; 


legal  because  4  bits 
are  sufficient 
illegal  because  1  bit  is 
not  enough  to  represent 
an  integer  of  subtype  S 


Notea  on  the  example: 

The  subtype  declaration  in  this  example  implies  an  integer  with  a  min¬ 
imum  size  of  four  bits.  However,  the  components  X  and  Y  of  subtype 
S  are  biased  and  can  be  stored  in  only  two  bits.  The  component  clause 
for  X  is  legal  because  it  requires  at  least  the  minimum  number  of  bits 
required  for  the  integer  subtype;  the  component  clause  for  Y  is  illegal 
because  it  does  not  allow  enough  bits  to  represent  the  integer  subtype. 


13.5  Address  Clauses 

The  following  information  supplements  paragraph  7: 

Like  VAX  Ada,  XD  Ada  supports  address  clauses. 

In  XD  Ada,  the  simple  name  must  be  the  name  of  a  variable.  XD  Ada 
does  not  allow  address  clauses  that  name  constants;  or  subprogram, 
package,  or  task  units. 

An  intermediate  pointer  is  created  only  if  the  resulting  address  is  not  a 
compile-time  constant. 

The  placement  of  an  address  clause  in  XD  Ada  must  follow  the  rules 
given  in  Section  13.1.  In  other  words,  the  clause  and  the  variable 
declaration  must  both  occur  immediately  within  the  same  declarative 
part  or  package  specification,  and  the  declaration  must  occur  before 
the  clause.  The  restrictions  for  forcing  occurrences  also  apply;  with 
respect  to  address  clauses,  any  occurrence  of  the  variable  name  after  its 
declaration  is  a  forcing  occurrence. 
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Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored. 

The  following  information  supplements  the  Notes  section: 

Also,  if  an  address  clause  is  specified  for  an  object  of  a  type  that  has 
been  declared  with  an  alignment  clause,  the  alignment  required  for  the 
address  is  checked  against  the  alignment  given  for  the  record  type.  If 
the  two  are  incompatible,  the  exception  PROGRAM.ERROR  is  raised. 

The  same  check  applies  to  a  type  that  contains  a  component  of  a  type 
that  has  been  declared  with  an  alignment  clause  (the  alignment  of  the 
component  forces  the  alignment  of  the  containing  type). 


13.5.1  interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  from  the  vector  base  register. 

XD  Ada  provides  the  additional  pragma  LEVEL.  This  pragma  is  given 
for  a  task  type,  or  single  task  of  anonymous  type,  and  gives  the  level  for 
its  interrupts. 

There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  MC68020 
Run-Time  Reference  Manual  gives  examples  ^f  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  run  at  interrupt  level  whilst 
accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of  the  same 
level  or  lower  levels  are  inhibited.  It  is  possible  to  lose  interrupts  with 
this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  behaves  like  an  •-■rdinary 
entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  behaves  like  a 
conditional  entry  call.  If  there  is  an  accept  statement  waiting  for  the 
interrupt,  the  body  of  the  accept  statement  is  executed  immediately. 
When  the  body  is  complete,  the  task  is  inserted  in  the  ready  queue 
and  the  interrupt  completed  by  a  retum-from-interrupt  instruction.  The 
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accept  statement  can  make  excursions  into  other  routines,  and  can  even 
make  entry  calls,  but  must  not  suspend  the  task  before  the  interrupt 
is  dismissed,  otherwise  the  program  repeatedly  services  the  interrupt 
unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 


13.7  The  Package  System 

'The  following  information  supplements  paragraph  1: 

XD  Ada  additions  to  the  package  SYSTEM  are  described  in  Section 
13.7a. 

The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  enumeration  literal  for  SYS'TEM.NAME  is  MC68020. 
‘The  following  information  supplements  paragraph  7: 

In  XD  Ada,  the  value  given  for  STORAGE_UNIT  must  be  8  (bits). 

The  following  Information  supplements  paragraph  9: 

In  XD  Ada,  the  number  given  for  MEMORY_SIZE  must  be  2* *31-1. 
Like  VAX  Ada,  XD  Ada  does  not  provide  support  for  checking  or 
ensuring  that  the  given  size  is  not  exceeded. 

The  following  information  supplements  paragraph  11: 

As  with  VAX  Ada,  XD  Ada  imposes  no  further  limitations  on  these 
pragmas.  To  reduce  the  amount  of  recompilation  required,  XD  Ada 
identifies  those  units  that  have  a  real  dependence  on  the  values  affected 
by  these  pragmas:  only  such  units  must  be  recompiled.  In  particular, 
predefined  XD  Ada  packages  do  not  depend  on  tne  values  affected  by 
these  pragmas,  and  none  require  recompilation  if  these  pragmas  are 
used. 


1 3.7a  XD  Ada  Additions  to  the  Package  SYSTEM 

In  addition  to  the  language-required  declarations  in  package  SYSTEM, 
XD  Ada  declares  the  operations,  constants,  types,  and  subtypes  de¬ 
scribed  in  the  following  sections. 
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13.7a.1  Properties  of  the  Type  ADDRESS 

In  XD  Ada,  ADDRESS  is  a  private  type  for  which  the  following  opera¬ 
tions  are  declared; 

Addreaa  type 

type  ADDRESS  la  private: 

ADDRESS_ZERO  I  ceaataat  ADDRESS; 

type  ADDRESS_INT  la  raapa  MIN_INT  ..  hax_INT; 

fuaetloa  TO_ADDRESS  (X  :  ADDRESS_INT)  ratura  ADDRESS; 

fuaetlea  TO_ADDReSS  (X  ;  (univeraal^integer) ;  ratura  ADDRESS; 

fuaetloa  TO~ADDReSS_INT  (X  i  ADDRESS)  ~  ratura  ADDRESS_INT; 

fuaetloa  (LEFT  i  ADDRESS;  RIGHT  i  ADDRESS_INT)  ratura  ADDRESS; 

fuaetloa  '*•  (LEFT  i  ADDRESS_INT;  RIGHT  :  ADDRESsT  ratura  ADDRESS; 

fuaetloa  (LEFT  i  ADDRESS;  RIGHT  t  ADDRESS)  ratura  ADDRBSS_INT; 

fuaetloa  (LEFT  l  ADDRESS;  RIGHT  i  ADDRBSS_INT)  ratura  ADDRESS? 


fuaetloa 

(LEFT, 

RIGHT 

t 

ADDRESS ) 

rotura 

BOOLEAN; 

—  fuaetloa 

’/-■  (LEFT, 

RIGHT 

: 

ADDRESS ) 

ratura 

BOOLEAN; 

fuaetloa 

•<•  (LEFT, 

RIGHT 

i 

ADDRESS ) 

rotura 

BOOLEAN ; 

fuaetloa 

•<-■  (LEFT, 

RIGHT 

X 

ADDRESS ) 

rotura 

BOOLEAN; 

fuaetloa 

“>"  (LEFT, 

RIGHT 

t 

ADDRESS) 

rotura 

BOOLEAN; 

fuaetloa 

•>-•  (LEFT, 

RIGHT 

t 

ADDRESS ) 

rotura 

BOOLEAN; 

Note  that  becauaa  ADDRESS  la  a  private  type 
the  functiona  and  "/-*  are  already  available 


—  Generic  functiona  uaad  to  accaaa  memory 

poaorle 

typo  TARGET  la  private; 

fuaetloa  FETCH.FROM. ADDRESS  (A  i  ADDRESS)  ratura  TARGET; 

foaorle 

typo  TARGET  la  private; 

proeo4uro  ASSIGN.TO.ADDRESS  (A  t  ADDRESS;  T  t  TARGET); 

The  addition,  subtraction,  and  relational  functions  provide  arithmetic 
and  comparative  operations  for  addresses.  The  generic  subprograms 
FETCH_FROM_ ADDRESS  and  ASSIGN_TO_ ADDRESS  provide  op¬ 
erations  for  reading  from  or  writing  to  a  given  address  interpreted  as 
having  any  desired  type.  ADDRESS_ZERO  is  a  deferred  constant  whose 
value  conesponds  to  the  first  (machine)  address. 


Propertfss  of  ths  Type  ADDRESS  I3.7a.l 


13-9 


In  an  instantiation  of  FETCH_FROM_ADDRESS  or  ASSIGN_TO_ 
ADDRESS,  the  actual  subtype  corresponding  to  the  formal  type  T 
must  not  be  an  unconstrained  array  type  or  an  unconstrained  type  with 
discriminants.  If  the  actual  subtype  is  a  type  with  discriminants,  the 
value  fetched  by  a  call  of  a  function  resulting  from  an  instantiation  of 
FETCH_FROM_ADDRESS  is  checked  to  ensure  that  the  discriminants 
satisfy  the  constraints  of  the  actual  subtype.  In  any  other  case,  no  check 
is  made. 

ExampI*: 

X  !  INTEGER; 

A  t  SYSTEM. ADDRESS  >-  X'ADDRESS;  —  legal 

faaetlea  FETCH  ia  aaw  rETCH_FROM_ADDRBSS( INTEGER) ; 
prec«a«ra  ASSIGN  ia  aaw  ASS IGN_T0~ADDRES5( INTEGER) ; 

X  1-  FSTCH(A);  —  li)ce  "X  i-  A.all;' 

ASSIGN(A,X);  --  li)ce  'A.all  !-  X;' 


13. 7a. 2  Typa  Claat  Enumaratlon  Type 

XD  Ada  declares  the  following  enumeration  type  for  identifying  the 
various  Ada  type  classes: 

type  TYPE_CLASS  ia  (TYPE_CLASS_ENUMERATION, 

TYPE~CLASS~INTEGER, 

TYPE~CLASS~FlXED_POINT, 

type3class3floatIng_point, 
type^class'array , 
type”class“record , 
type~class”access, 
type"class~task, 

TYPb”cLASS~ADDRESS) ; 

In  addition  to  the  usual  operations  for  discrete  types  (see  Section  3.5.5), 
XD  Ada  provides  the  attribute  TYPE.CLASS. 

For  every  type  or  subtype  T: 

T'TYPE.CLASS  Yields  the  value  of  the  type  class  for  the  full  type  of 
T.  If  T  is  a  generic  formal  type,  then  the  value  is  that 
for  the  corresponding  actual  subtype.  The  value  of 
this  attribute  is  of  the  type  TYPE_CLASS. 

This  attribute  is  only  allowed  if  its  unit  names  the  predefined  package 
SYSTEM  in  a  with  clause. 
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I3.7a.2  Type  Class  Enumeration  Type 


Example!): 

Given 


typ«  MY_INT  la  rang#  1..10; 
typa  NEW_INT  ia  aaw  STRING; 
packaga  PACK  la 

typa  PRIV  la  prlvata; 
prlvata 

typa  PRIV  la  aaw  FLOAT: 
aad  PACK; 

then 

—  MY_INT'TYPE_CLASS  equals  TYPE_CLASS_ INTEGER 

—  NEW_INT'TYPE_CLASS  equals  TYPE^CLASs'aRRAY 

—  PRIV'TYPE_CLASS  equals  TYPb2cLASS”fLOATING_POINT 


13.7a. 3  Hardware-Oriented  Types  and  Functions 

XD  Ada  declares  the  following  types,  subtypes,  and  functions  for 
convenience  in  working  with  MC68020  hardware-oriented  storage: 


—  XD  Ada  hardware-oriented  typea  and  functions 

typa  BIT_ARRAY  la  array  (INTEGER  raaga  <>)  of  BOOLEAN; 
pragaa  PACK( BIT_ARRAY ) ; 

aubtypa  BIT_ARRAY_8  la  BIT_ARRAY  (0  ..  7); 

aabtypa  BIT^ARRAY^ie  la  BIT_ABRAY  (0  ..  15); 

aabtypa  BIT~ARRAY~32  la  BIT^ARRAY  (0  ..  31); 

aabtypa  BIT^ARRAy'S!  la  BIt'array  (0  ..  63); 

typa  UNSIGNio.BYTi  la  raaga  0  ..  255; 
far  UNSIGNeO^BYTE'StZB  uaa  8; 

fuaetlaa  'not*  (LEFT  t  UNSIGNBD_BYTE)  ratura  UNSIGNBD_BYTE; 

fuaetlea  *and’  (LEFT,  RIGHT  :  UNSIGNBD^BYTE)  ratura  ONSIGNED^BYTE; 

fuaetlaa  'or*  (LEFT,  RIGHT  i  UNSIGNE0~BYTE)  ratura  UNSIGNED~BYTE: 

fuaetlaa  'xor*  (LEFT,  RIGHT  i  UNSIGNEd'byTB)  ratura  UNSIGNED^BYTE; 

fuaetlaa  TO_UNSIGNEO_BYTB  (X  t  BIT_ABRAY_8)  ratura  UNSIGNED  BYTE; 
fuaetlea  T0_BIT_ARRAY_8  (X  :  UNS1GNED_BYTE)  ratura  BIT_ARRAY_8: 

typa  UNSIGNE0_BYTE_ARRAY  la  array  (INTEGER  raaga  <>)  of  UNSIGNED  BYTE; 
typa  UNSIGNBD^HORD*  la  raaga  0  ..  65S3S; 
far  UNSIGNB0~H0R0'SIZE  uaa  16; 

fuaetlaa  'not"  (LEFT  i  0NSIGNBD_W0RD(  ratura  UNSIGNED_WORD; 

fuaetlaa  'and*  (LEFT,  RIGHT  t  UNSIGNED' WORD)  ratura  UNSIGNEd'norD; 

fuaetlaa  'or*  (LEFT,  RIGHT  t  UNSIGNED^hORO)  ratura  UNSIGNED^HORD; 

fuaetlaa  -xor’  (LEFT,  RIGHT  i  UNSIGNEd'hORD)  ratura  UNSIGNEd'nORO; 

fuaetlea  TO_UNSIGNED_WORD  (X  i  BIT_ARRAY_ 16 )  ratura  UNSIGNED  MORD; 
fuaetlaa  To”bIT_ARRAY_16  (X  ;  UNSIGNED_W0RD)  ratura  BIT_ARRAY_16; 
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typ«  UNSIGNED_W0RD_ARRAY  is  array  ( It4TEGER  rasya  <>)  of  UNSIGNED  WORD; 


typa  UNSIGNED_LONGWORD  is  raaga  MIN_INT  ..  MAX_INT; 
for  UNSIGNED_LONGWORD'SIZE  usa  32; 


fuaetloa  'not* 
(uaetloB  'and* 
fuaetloa  'or* 
fuaetloa  *xor* 


(LEET 

(LEFT, 

(LEFT, 

(LEFT, 


:  UNSIGNED. 
RIGHT  «  UNSIGNED 
RIGHT  I  unsigned' 
RIGHT  t  unsigned' 


LONGWORD)  rotura 
LONGWCRO)  rotura 
LONGWORD)  rotura 
LONGWORD)  rotura 


UNS I GNED_  LONGWORD; 
UNS I GN  Ed2  LONGWORD ; 
UNS I GNEd” LONGWORD ; 
unsigned” LONGWORD ; 


fuaetloa  TO_UNSIGNED_LONGWORD  (X  t  BIT_ARRAY_32 )  rotura  UNSIGNED_LONGWORD; 
fuaetloa  TO_BIT_ARRAY_32  (X  i  UNSIGNED_WORD)”ratura  BIT_ARRAY_327 

trf*  UNSIGNED_LONGWORD_ARRAY  Is  array  (INTEGER  raaga  <>)  of  UNSIGNED_LONGWORD; 


13. 7a. 4  Conventional  Names  for  Unsigned  Longwords 

The  following  XD  Ada  declarations  provide  conventional  names  for 
Static  subtypes  of  the  predefined  type  UNSlGNED_LONGWORD: 


subtype 

UNSIGNED_ 

1 

la 

UNSIGNED. 

LONGWORD 

raag# 

0 

2L*  -l-l; 

subtype 

UNSIGNED_ 

2 

is 

UNSIGNED. 

LONGWORD 

ruy# 

0 

2**  '2-1; 

subtypo 

UNSIGNED_ 

3 

la 

UNSIGNED. 

LONGWORD 

0 

2**  3-1; 

subtypo 

UNSIGNED. 

4 

la 

UNSIGNED. 

LONGWORD 

0 

2**  4-1; 

subtype 

UNSIGNED. 

5 

la 

UNSIGNED. 

LONGWORD 

rM9« 

0 

2**  5-1; 

subtype 

UNSIGNED. 

6 

la 

UNSIGNED. 

LONGWORD 

raaf* 

0 

2**  6-1; 

subtype 

UNSIGNED. 

7 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**  7-1; 

subtype 

UNSIGNED. 

8 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**  8-1; 

subtype 

UNSIGNED. 

9 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**  9-1; 

subtype 

UNSIGNED. 

10 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2*»10-1; 

subtype 

UNSIGNED. 

n 

la 

UNSIGNED. 

LONGWORD 

0 

2**11-1; 

subtype 

UNSIGNED. 

12 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2*»12-1 

subtype 

UNSIGNED. 

13 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**13-1 

subtype 

UNSIGNED. 

14 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2««14-1 

subtype 

UNSIGNED. 

15 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2«»15-1 

subtype 

UNSIGNED. 

16 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2*»16-1 

subtype 

UNSIGNED. 

17 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2»«17-1 

subtype 

UNSIGNED. 

18 

la 

UNSIGNED 

LONGWORD 

raaga 

0 

2*»18-1 

subtype 

UNSIGNED. 

19 

la 

UNSIGNED.LONGWORD 

raaga 

0 

2»»19-1 

subtype 

UNSIGNED. 

20 

la 

UNSIGNED 

LONGWORD 

raaga 

0 

2»*20-l 

subtype 

UNSIGNED. 

21 

la 

UNSIGNED  LONGWORD 

raaga 

0 

2*»21-1 

subtype 

UNSIGNED 

22 

la 

UNSIGNED 

LONGWORD 

raaga 

0 

2**22-l 

subtype 

UNSIGNED. 

23 

la 

UNSIGNED.LONGWORD 

raaga 

0 

2**23-l 

subtype 

UNSIGNED. 

24 

la 

UNS I GNED. LONGWORD 

raaga 

0 

2««24-l 

subtype 

UNSIGNED  25 

la 

UNS I GNED.LONGWORD 

raaga 

0 

2**25-l 

subtype 

UNSIGNED 

26 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2»*26-l 

subtype 

UNSIGNED. 

27 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**27-l 

subtype 

UNSIGNED  28 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2*«28-l 

subtype 

UNSIGNED 

29 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2**29-l 

subtype 

UNSIGNED  30 

la 

UNSIGNED  LONGWORD 

raaga 

0 

2»»30-l 

subtype 

UNSIGNED. 

.31 

la 

UNSIGNED. 

LONGWORD 

raaga 

0 

2«*31-1 
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13.7.1  System-Dependent  Named  Numbers 

In  XD  Ada,  the  values  for  systenn-dependent  named  numbers  are  as 
shown  in  the  following  table. 


Attribute 

MC68020 

MINJNT 

-2^’ 

MAX.INT 

2’'-l 

MAX.DIGITS 

18 

MAX.MANTISSA 

31 

FINE.DELTA 

2.0-^' 

TICK 

162.5  X  10-‘ 

13.7.2  Representation  Attributes 

The  following  information  suppicmenta  all  of  thia  section: 

For  any  object,  program  unit,  label,  or  entry  X: 

X '  ADDRESS  Yields  the  address  of  the  first  of  the  storage  ele¬ 

ments  allocated  to  X.  For  a  subprogram,  package, 
task  unit  or  label,  this  value  refers  to  the  machine 
code  associated  with  the  corresponding  body  or 
statement.  For  an  entry  for  which  an  address 
clause  has  been  given,  the  value  refers  to  the  offset 
of  the  interrupt  vector  from  the  vector  base  register. 
The  value  of  this  attribute  Is  of  the  type  ADDRESS 
defined  in  the  package  SYSTEM. 

For  an  object  that  is  a  variable,  the  value  is  the  ac¬ 
tual  address  of  the  variable  (which  may  be  statically 
or  dynamically  allocated),  lliis  attribute  forces  a 
variable  to  be  allocated  in  memory  rather  than  in 
a  register,  and  causes  the  variable  to  be  marked  as 
volatile  for  the  duration  of  the  block  statement  or 
body  containing  use  of  the  attribute.  If  the  location 
of  the  variable  is  not  byte-aligned,  the  value  is 
the  address  of  the  lowest  byte  that  contains  the 
variable.  For  an  object  that  is  a  constant,  the  value 
is  the  address  of  the  constant  value  in  memory; 
however,  two  occurrences  of  C' ADDRESS,  where 
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C  denotes  a  constant,  may  or  may  not  yield  the 
same  address  value.  For  an  object  that  is  a  named 
number,  the  value  is  zero  (ADDRESS.ZERO). 

NOTE 

In  the  context  of  these  representation 
attributes,  ADDRESS.ZERO  means  only 
that  no  useful  interpretation  of  a  nonzero 
value  is  currently  supported.  That  is,  its 
use  as  a  result  of  C' ADDRESS  is  subject 
to  change. 

For  an  access  object,  X.all' ADDRESS  is  the  address 
of  the  designated  object;  X.all'ADDRESS  is  subject 
to  an  ACCESS_CHECK  for  the  designated  object. 
For  a  record  component,  X.C' ADDRESS  is  subject 
to  a  DISCRIMINANT.CHECK  for  an  object  in 
a  variant  part.  For  an  array  component  or  slice, 
X(I)' ADDRESS  or  X(I1... 12)' ADDRESS  is  subject  to 
an  INDEX_CHECK  for  the  denoted  component  or 
slice. 

For  program  units  that  are  task  units  or  package 
units,  the  value  is  zero  (ADDRESS_ZERO).  For 
program  units  that  are  subprograms,  the  value  is 
the  same  as  the  address  that  would  be  exported. 
(See  Section  I3.9a.l.4  (LRM)  for  information  on 
pragmas  EXPORT  FUNCTION  and  EXPORT 
PROCEDURE). 

For  entries,  the  value  is  zero  (ADDRESS.ZERO). 

For  labels,  the  value  is  the  address  of  the  machine 
code  which  follows  the  label. 

For  any  type  or  subtype  X,  or  for  any  object  X: 

X '  SIZE  For  a  type  or  a  subtle,  the  value  is  limited  to 

values  in  the  range  6  ..  MAX.INT;  the  exception 
NUMERIC. ERROR  (see  Section  11.1)  is  raised  for 
values  outside  this  range.  For  an  object  that  is  a 
variable  or  a  constant  in  XD  Ada,  the  value  is  its 
size  in  bits.  For  an  object  that  is  a  named  num¬ 
ber,  the  value  is  zero.  For  a  record  component, 
X.C 'SIZE  is  subject  to  a  DISCRIMINANT.CHECK 
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for  an  object  in  a  variant  part.  For  an  array  compo¬ 
nent  or  slice,  X(I)'SIZE  or  X(I1.  .I2)'SIZE  is  subject 
to  an  INDEX_CHECK  for  the  denoted  component 
or  slice. 

For  any  type  or  subtype  X: 

X'MACHINE_SIZE  Yields  the  number  of  machine  bits  to  be  allocated 
for  variables  of  the  type  or  subtype.  This  value 
takes  into  account  any  padding  bits  used  by  XD 
Ada  when  allocating  a  variable  on  a  byte  boundary. 
The  value  of  this  attribute  is  of  the  type  uiiiversal_ 
integer. 

The  value  is  always  a  multiple  of  8  (bits).  In  partic¬ 
ular,  for  discrete  types  it  is  8,  16,  or  32.  The  value 
is  limited  to  the  range  O..MAX_INT;  the  exception 
NUMERIC.ERROR  is  raised  for  values  outside  this 
range. 

For  any  object  X: 

X '  BIT  Yields  the  bit  offset  within  the  storage  unit  (byte) 

that  contains  the  first  bit  of  the  storage  allocated  for 
the  object.  The  value  of  this  attribute  is  of  the  type 
miifersaljnteger,  and  is  always  in  the  range  0..7. 

For  an  object  that  is  a  variable  or  a  constant  al¬ 
located  in  a  register,  the  value  is  zero.  (The  use 
of  this  attribute  does  not  force  the  allocation  of 
a  variable  to  memory.)  For  an  object  that  is  a 
formal  parameter,  this  attribute  applies  either 
to  the  matching  actual  parameter  or  to  a  copy 
of  the  matching  actual  parameter.  For  an  ac¬ 
cess  object,  the  value  is  zero  (in  the  absence  of 
CONSTRAINT.ERROR);  X.all'Bnr  is  subject  to 
an  ACCESS.CHECK  for  the  designated  object. 

For  a  record  component,  X.C'BIT  is  subject  to 
a  DISCRIMINANT.CHECK  for  a  component  in 
a  variant  part.  For  an  array  component  or  slice, 
X(1)'BIT  or  X(I1..12)'BIT  is  subject  to  an  INDEX. 
CHECK  for  the  denoted  component  or  slice. 
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The  following  information  supplements  the  Notes  section: 

The  attribute  X'MACHINE.SIZE  gives  the  size  that  would  be  used  for 
a  variable  of  the  type  or  subtype;  it  does  not  give  the  size  that  may  be 
used  for  a  component  of  that  type  or  subtype. 

The  machine  size  of  a  type  or  subtype  can  be  influenced  by  representa¬ 
tion  clauses,  unlike  the  size  of  a  type  or  subtype,  which  is  independent 
of  representation  clauses.  The  machine  size  of  a  base  type  can  be  less 
than,  equal  to,  or  greater  than  the  size  of  that  same  base  type.  See  the 
XD  Ada  MC68020  Run-Time  Reference  Manual  for  examples  and  additional 
discussion. 


13.7.3  Representation  Attributes  of  Reai  Types 

The  following  information  supplements  paragraphs  3  and  4: 

For  both  fixed-  and  floating-point  types: 

T'MACHINE.ROUNDS  In  XD  Ada  this  value  is  FALSE 

T '  MACHINE.OVERFLOWS  In  XD  Ada  this  value  is  FALSE 

The  XD  Ada  values  of  the  other  representation  attributes  for  floating¬ 
point  types  are  dependent  on  the  Hoating-point  type  and  are  listed  in 
Appendix  F. 


1 3.8  Machine  Code  Insertions 

The  following  information  supplements  paragraph  4: 

XD  Ada  provides  the  package  MACHINE.CODE.  Machine  code  inser¬ 
tions  can  be  expanded  in  line. 

This  predefined  package  and  not  a  user-defined  package  must  be 
named  in  a  with  clause  that  applies  to  the  compilation  unit  in  which  the 
code  statement  occurs. 

The  following  is  an  example  of  MACHINE_CODE  and  the  with  clause 
in  use: 
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--  A  rachine  code  procedure  *-o  e-.^l'^ate  the  sine  and  cosine  of 
--  parameter  X,  returninq  h  >  results  in  parameters  V  and  ’ 

--  respectively:  the  procedure  is  to  he  expanded  in  line,  so 
--  it  does  not  require  a  stack  frame  of  its  own: 
with  MACHINE_CC'DE; 

procedure  SI NCOS  1  (  X:  in  FLOAT; 

Y;  out  FLOAT; 

Z:  out  FLOAT  I  Lm 
use  MACHINE_CCDE; 
bopia  FSINCOS_REG_INST'  ( 

OPCODE  •>  FSINCOS, 

SOURCE_REGISTER  ->  FPO , 

SIN_REGISTER  ->  FPl, 

COs'reGISTER  ->  FP2  ); 


ead  SINCOSl; 

XD  Ada  provides  the  pragma  CALL_SEQUENCE_PROCEDURE  which 
specifies  parameter-passing  mechanisms  for  machine  code  procedures. 
The  pragma  is  defined  in  Appendix  B.  Examples  of  machine  code 
insertion  are  given  in  Section  6.1  of  the  XD  Ada  MC68020  Run-Time 
Reference  Manual.  For  the  specification  of  the  package  MACHINE_ 
CODE,  see  Appendix  B  of  the  XD  Ada  MC68020  Run-Time  Reference 
Manual. 


1 3.9  Interface  to  Other  Languages 

The  following  information  supplements  paragraph  4: 

As  with  VAX  Ada,  use  of  pragma  INTERFACE  in  XD  Ada  is  interpreted 
as  being  equivalent  to  supplying  the  body  of  the  named  subprogram  or 
subprograms.  Therefore,  the  following  rules  apply: 

•  If  a  subprogram  body  is  given  later  for  a  subprogram  named  with 
pragma  INTERFACE,  the  body  is  illegal. 

•  If  pragma  INTERFACE  names  a  subprogram  body,  the  pragma  is 
illegal. 

•  If  a  duplicate  pragma  INTERFACE  is  given,  the  latter  pragma  is 
illegal. 

In  XD  Ada,  pragma  INTERFACE  applies  to  a  renaming  only  if  the 
renaming  c"urs  in  the  same  declarative  part  or  package  specification 
as  the  pragma.  The  renamed  subprogram  must  also  occur  in  that  same 
declarative  part  or  package  specification;  renamed  subprograms  that 
occur  outside  the  declarative  part  or  package  specification  are  ignored 
(without  a  warning  diagnostic). 
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In  addition,  XD  Ada  interprets  the  effect  of  pragma  INTERFACE  in  such 
a  way  that  it  accepts  and  ignores  implicit  declarations  of  subprograms 
(such  as  predefined  operators,  derived  subprograms,  attribute  functions, 
and  so  on). 

Dependent  upon  its  use  in  an  XD  Ada  program,  pragma  INTERFACE  is 
interpreted  in  combination  with  one  of  two  XD  Ada  import  subprogram 
pragmas:  IMPORT.FUNCTION  or  IMPORT.PROCEDURE.  These 
pragmas  are  described  in  Section  13.9a.  1. 

The  language  name  is  ignored,  and  so  may  be  any  identifier  that 
suggests  the  language,  source,  or  nature  of  the  imported  subprogram. 

If  pragma  INTERFACE  is  used  without  one  of  these  import  pragmas,  a 
default  interpretation  is  used,  as  follows: 

•  If  the  subprogram  name  applies  to  a  single  subprogram,  then  a 
default  import  pragma  is  assumed  as  follows: 

For  a  function,  the  default  is  as  follows: 

pragaa  I MPORT_ FUNCTION  ( f unction_designator ) ; 

For  a  procedure,  the  default  is  as  follows: 

prafM  IMPORT_PROCBDURE  ( procedure_ident i f ier ( ; 

•  If  the  subprogram  name  applies  to  two  or  more  subprograms,  the 
pragma  applies  to  all  of  them.  However,  a  warning  is  given  if  the 
appropriate  XD  Ada  import  pragmas  are  not  given  for  all  of  the 
subprograms. 

Whether  or  not  pragma  INTERFACE  is  used  with  an  import  pragma,  the 
subprogram  name  must  be  an  identifier,  or  a  string  literal  that  denotes 
an  operator  symbol.  In  the  following  example,  pragma  INTERFACE 
specifies  that  the  indicated  routines  SQRT  and  EXP  are  to  be  imported 
and  used  as  bodies  for  the  XD  Ada  functions  SQRT  and  EXP  in  package 
FORT.LIB: 

pachae*  FORT_LIB  ta 

fuaetioa  iQRT(X  ;  FLOAT)  ratura  FLOAT; 
fuaetiaa  EXP(X  s  FLOAT)  ratura  FLOAT; 
prtvata 

prafM  INTERFACE! FORTRAN,  SQRT); 
prafM  INTERFACE! FORTRAN,  EXP); 
aae  FORT  LIB; 
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The  following  information  supplements  paragraph  5: 

In  XD  Ada,  the  example  package  FORT.LID  is  interpreted  as  follows: 
pragma  INTERFACE  specifies  that  the  indicated  rontines  SQRT  and 
EXP  are  to  be  imported  and  used  as  bodies  for  the  Ada  functions  SQRT 
and  EXP  in  package  FORT_LIB. 

packaga  CHOOSE_R  la 

procadura  P(X  :  IMTEGERl; 
proeadura  P(X  :  FLOAT ); 

prtvata 

procadura  R(X  :  FLOAT)  ranaaaa  P; 

pragma  INTERFACE) ASSEMBLER,  R); 
aad  CHOOSE_R; 

In  this  example,  pragma  INTERFACE  indicates  that  the  body  for  the 
second  procedure  P  is  to  be  imported  as  routine  R. 

The  following  information  supplements  the  Notes  section: 

The  meaning  of  the  subprogram  name  is  determined  as  for  any  name 
(see  Section  8.3  (LRM)),  except  that  the  name  can  denote  more  than  one 
subprogram.  Thus,  in  the  following  declaration  the  pragma  INTERFACE 
applies  to  the  first  two  procedures;  it  does  not  apply  to  the  third 
because  the  declaration  is  not  visible  at  the  place  of  the  pragma. 

procedure  P  (B:  BOOLEAN); 
procedure  P  (I:  INTEGER); 
pragma  INTERFACE  (ASSEMBLER,  P); 
procedure  P  ( F :  FLOAT ) ; 

This  same  interpretation  is  made  for  pragmas  used  to  import  and  export 
subprograms  (see  Section  13.9a. 1). 

If  pragma  INTERFACE  and  pragma  INLINE  are  used  together,  the 
pragma  INLINE  is  ignored  regardless  of  the  order  in  which  the  two 
pragmas  appear. 

Refer  to  Chapter  3  of  the  XD  Adn  MC68020  Run-Time  Reference  Manual 
for  subprogram  calling  conventions  and  run-time  organisation,  while 
Chapter  6  of  the  same  manual  describes  low-level  interfaces  and  assem¬ 
bly  language  modules. 
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13.9a  XD  Ada  import  and  Export  Pragmas 


XD  Ada  provides  import  and  export  pragmas  designed  specifi¬ 
cally  for  constructing  programs  composed  of  both  Ada  and  non- 
Ada  entities.  The  import  pragmas  allow  an  Ada  program  to  refer 
to  entities  written  in  another  language;  the  export  pragmas  make 
Ada  entities  available  to  programs  written  in  other  languages. 

The  names  of  the  pragmas  indicate  the  kind  of  entity  involved: 
IMPORT_FUNCTION  and  EXPORT_FUNCT!ON  apply  to  nongeneric 
functions;  IMPORT.PROCEDURE  and  EXPORT.PROCEDURE  apply  to 
nongeneric  procedures;  IMPORT.OBJECT  and  EXPORT.OBJECT  apply 
to  objects;  and  IMPORT.EXCEPTION  and  EXPORT.EXCEPTION  apply 
to  exceptions.  These  pragmas  are  described  in  this  section,  summarized 
in  Annex  B,  and  listed  in  Appendix  F 

All  the  XD  Ada  import  and  export  pragmas  have  the  following  form: 

prmgmm  inport_export_pragma_name 

( internal_n4me  (,  external_designator ) 

[,  pragma_specif ic_options ) )  ; 

import_export_pragma_naine 

EXPORT_EXCEPTION  |  BXPORT_ FUNCTION 
I  EXPORT_OBJECT  j  EXPORt”pROCBDURE 
I  IMPORT_EXCEPTION  j  IMPCRT_FUNCTION 
I  IMPORT_OBJECT  j  tMPORT_PROCEDURE 

internal_name  (INTERNAL  ->)  simple_name 

I  (INTERNAL  -> )  operat jr_syTnbol  —  Can  be  used  only  tor 

—  I«PORT_FUNCTION 

external_de«ignator  s:-  (EXTERNAL  ->)  external_symbol 

external_«ymbol  identifier  |  string_l iteral 

The  internal  name  can  be  an  Ada  simple  name,  or,  if  the  declared  entity 
is  a  function,  the  internal  name  can  be  a  string  literal  that  denotes  an 
operator  symbol.  A  subprogram  to  be  imported  or  exported  must  be 
identified  by  its  internal  name  and  parameter  types;  and,  in  the  case  of 
a  function,  by  the  result  type  (see  Section  13. 9a.  1.1). 

The  external  designator  determines  a  symbol  that  is  referenced  or 
declared  in  the  linker  object  module.  If  an  identifier  is  given,  the 
identifier  is  used.  If  a  string  literal  is  given,  the  value  of  the  string  is 
used.  The  value  of  a  string  literal  must  be  a  symbol  that  is  acceptable 
to  the  XD  Ada  Builder;  it  need  not  be  valid  as  an  Ada  identifier.  (For 
example,  the  dollar  character  ($)  can  be  used.)  If  no  external  designator 
is  given,  the  internal  name  is  used  as  the  external  designator.  If  the 
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external  designator  (explicit  or  default)  is  longer  than  12  characters,  the 
import  or  export  pragma  is  ignored 

Pragma-specific  options  are  described  in  the  individual  pragma  sections 
that  follow. 

The  XD  Ada  import  and  export  pragmas  are  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply  to  an  entity  declared  by  an  earlier 
declarative  item  of  the  same  declarative  part  or  package  specification. 

At  most  one  import  or  export  pragma  is  allowed  for  any  given  entity;  in 
the  case  of  multiple  overloaded  subprograms,  this  rule  applies  to  each 
subprogram  independently. 

Additional  placement  and  usage  rules  apply  for  particular  pragmas  as 
described  in  the  following  sections. 

Note: 

Argument  associations  for  XD  Ada  import  and  expcii  pragmas  can  be 
either  positional  or  named.  With  positional  association,  the  arguments 
are  interpreted  in  the  order  in  which  they  appear  in  the  syntax  defini¬ 
tion.  The  rules  for  the  mixing  of  positional  and  named  association  are 
the  same  as  those  that  apply  to  subprograms  (see  Section  6  4  (LRM)). 

A  pragma  for  an  entity  declared  in  a  package  specification  must  not  be 
given  in  the  package  body.  (A  pragma  for  an  entity  given  in  the  visible 
part  of  a  package  specification  can,  however,  be  given  in  either  the 
visible  or  private  part  of  the  specification.) 

No  checking  is  provided  to  ensure  that  exported  symbols  do  not  con¬ 
flict  with  each  other  or  with  other  global  symbols;  such  checking  is 
performed  by  the  XD  Ada  Builder. 


13.9a.1  Importing  and  Exporting  Subprograms 

XD  Ada  provides  a  series  of  pragmas  that  make  it  possible  to  call 
nongeneric  subprograms  in  a  mixed-language  programming  environ¬ 
ment.  The  IMPORT.FUNCTION  and  IMPORT.PROCEDURE  pragmas 
specify  that  the  body  of  the  subprogram  associated  with  an  Ada  sub¬ 
program  specification  is  to  be  provided  from  assembly  language. 
Pragma  IhfrERFACE  must  precede  one  of  these  import  pragmas  (see 
Section  13.9).  The  EXPORT.FUNCTION  and  EXPORT.PROCEDURE 
pragmas  allow  an  .Ada  procedure  or  function  to  be  called  from  assem¬ 
bly  language.  The  pragmas  support  parameter  passing  by  means  of 
registers. 
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13. 9a. 1.1  Importing  Subprograms 

XD  Ada  provides  tvvo  pragmas  for  importing  subprograms: 
IMPORT.FUNCTION  and  IMPORT.PROCEDURE.  These  pragmas 
allow  the  import  of  the  kind  of  subprograms  indicated. 

The  pragmas  for  importing  subprograms  have  the  following  form: 

prafM  I MPORT_ FUNCTION  |  :mPOBT_PROCEDURE 

((  INTERNAL  =>|  internal_name 
(,  (EXTERNAL  •> |  external_des iqnator  ] 

(,  ( PARAMETER_TYPES  »■» )  (  parajneter_t ypes  )  ) 

(,  (RESULT_TYPE  -> )  type_mar)t  )  --  FUNCTION  only 

(,  [MECHANISM  •>)  mechanism  ) 

(,  ( RESULT_MECHANISM  -> (  mechanism_spec  |  --  FUNCTION  only 

(,  i PRESERVED_REGISTERS  ->  J  (  registers  )  [ 

)  ; 

paraneter_types 

null  I  type_mark  (,  type_marlc) 

mechanism  t:“ 

mechaniam_spec  |  (  mechanism_spec  (,  mechani8m_SpM )  ) 
mechanism_apec 

mechaniam_nan>e  (  (  (REGISTER  ->  )  reqister_name  )  ) 
mechanisra_name  i:- 

value”  I 

REFERENCE  j  BIT_REFERENCE  | 

DOPE_VECTOR  j  BIt”dOPE_VECTOR 

registers  s:- 

aull  I  regiater_name  {,  register_name  ) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  ^pes 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol  that 
is  associated  with  the  external  subprogram.  If  no  external  designator  is 
given,  the  internal  name  is  used  as  the  global  symbol. 
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The  parameter  t\'pes  option  specifies  a  series  of  one  or  more  type 
marks  (t\'pe  or  subtype  names),  not  parameter  names  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

Mechanism  names  are  described  as  follows.  Within  these  definitions, 
the  term  bit  string  means  any  one-dimensional  array  of  a  discrete  type 
whose  components  occupy  successive  single  bits.  The  term  simple 
record  type  means  a  record  type  that  does  not  have  a  variant  part  and  in 
which  any  constraint  for  each  component  and  subcomponent  is  static. 

A  simple  record  subtype  is  a  simple  record  type  or  a  static  constrained 
subtype  of  a  record  type  (with  discriminants)  in  which  any  constraint  for 
each  component  and  subcomponent  of  the  record  type  is  static. 

VALUE  Specifies  that  the  immediate  value  of  the  actual 

parameter  is  passed.  Values  of  scalars,  access 
types,  address  types  and  private  types  whose 
full  type  is  either  a  scalar,  an  access  type  or  an 
address  type  can  be  passed  by  VALUE.  If  the 
value  is  a  private  type,  the  pragma  must  occur 
after  the  full  declaration  of  the  private  type.  Bit 
strings  can  also  be  passed  by  VALUE. 

REFERENCE  Specifies  that  the  address  of  the  value  of  the 

actual  parameter  is  passed.  This  mechanism  can 
be  used  for  parameters  of  any  type. 

DOPE_ VECTOR  Specifies  that  the  address  of  the  DOPE. VECTOR 
is  passed,  a  32-bit  pointer  to  an  object,  taking 
the  form  described  in  Section  2.1.4  of  the  XD 
Ada  MC68020  Run-Time  Reference  Manual. 

BIT  DOPE.VECTOR  Specifies  that  the  address  of  the  BIT.DOPE. 

VECTOR  is  passed,  a  32-bit  pointer  to  an  object, 
taking  the  form  described  in  Section  2.1.4  of  the 
XD  Ada  MC68020  Run-Time  Reference  Manual. 
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If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
subprograms  are  as  follows; 

•  If  an  import  pragma  is  given  for  a  subprogram  specification,  pragma 
INTERFACE  (see  Section  13.9)  must  also  be  given  for  the  subpro¬ 
gram  earlier  in  the  same  declarative  part  or  package  specification. 
The  use  of  pragma  INTERFACE  implies  that  a  corresponding  body 
is  not  given. 

•  If  a  subprogram  has  been  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  These  pragmas  can  be  used  for  subprograms  declared  with  a  re¬ 
naming  declaration.  The  internal  name  must  be  a  simple  name,  and 
the  renaming  declaration  must  occur  in  the  same  declarative  part 
or  package  specification  as  the  pragma.  The  renamed  subprogram 
must  also  occur  in  that  same  declarative  part  or  package  specifica¬ 
tion.  Renamed  subprograms  that  occur  outside  the  declarative  part 
or  package  specification  are  ignored  (without  a  warning  diagnostic). 

•  None  of  these  pragmas  can  be  used  for  a  generic  subprogram  or 
a  generic  subprogram  instantiation.  In  particular,  they  cannot  be 
used  for  a  subprogram  that  is  declared  by  a  generic  instantiation  of 
a  predefined  subprogram  (such  as  UNCHECKED_CONVERSION). 
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Examplas: 

In  this  example,  the  pragma  INTERFACE  identifies  SQRT  as  an  external 
subprogram;  the  language  name  argument  ASSEMBLER  has  no  effect. 
The  pragma  IMPORT_FUNCTION  uses  positional  notation  to  specify 
arguments  for  importing  the  declared  function  SQRT,  The  pragma  form 
indicates  that  the  internal  name  is  SQRT,  and  the  external  designator  is 
'MTFiSSQRT'.  The  parameter  is  of  type  FLOAT,  and  is  passed  in  FPl; 
the  result  is  of  type  FLOAT,  and  it  is  returned  in  FP2. 


fuaetloB  SQRT  (X  :  FLOAT  )  ratura  FLOAT; 
pra«Ba  INTERFACE  (ASSEMBLER,  SQRT); 
pragma  I MPORT_ FUNCTION 

(iORT,  'MTHSSQRT-,  ( FLOAT  I , 
FLOAT,  (VALUE( FPl ) ) ,  VALUE(FP2) 
)  : 


The  next  example  shows  an  alternative  way  of  importing  the  declared 
function  SQRT  using  named  notation.  In  this  case,  the  parameter  is 
passed  in  FP5,  and  the  result  is  returned  in  FP4;  the  registers  which  are 
preserved  by  the  called  function  are  also  specified. 


fuaetloa  SQRT  (X  ;  LONG_FLOAT  )  ratura  LONG_FLOAT;  '  ' 

pragma  INTERFACE  (ASSEmBlER,  SQRT I ; 

pragma  IMPORT_FUNCTtON  (INTERNAL  ->  SQRT, 

PARAMETER_TYPES  ->  ( LONG_FLOAT | , 

RESULT_TYPE 
MECHANISM 
RESULT_MECHAN I SM 
EXTERNAL  -> 

PRESERVEO_REGISTERS  -> 

(DO,  Dl,  D2,  D3,  D4, 

AO,  Al,  A2,  A3,  A4, 

FPO,  FPl,  FP2,  FP3, 


->  LONG_ FLOAT, 

->  ( VALUE ( FP5 ) I , 
->  VALUE (rP4), 

->  *MTHSDSQRT', 


D5,  D6,  07, 

AS, 

FPS,  FPS))! 


If  the  previous  example  is  combined  with  the  code  in  the  first  example 
(that  is,  with  only  one  occurrence  of  pragma  INTERFACE),  the  result  is 
an  overloading  of  SQRT: 
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function  ?;RT  (X  :  :  r;  AT  i  roturn  L  AT; 

function  S^RT  (X  :  FL  AT  t  roturn  FL.'AT; 
pragma  '.NTERFATE  (ASSEKPLER,  .i.'RT); 
pragma  IMF 'RT_Fl'NCT!  :n  (S;nT, 

•■“th$s::rt- . 

I  FL.'ATI , 

FLTAT, 

( VALUE ( FPl n , 

VALUE ( FP: ) ) ; 

pragma  I MPORT_ FUNCTION  ( INTERNAL 

PARAMETER_TYPES 
RESL-LT_TYPE 

mechanIsm 

RESULT_MECHANISM 
EXTERNAL 
PRESERVED_REGISTERS  -> 

(00.  01,  02,  03,  04,  05,  06,  07, 

AO,  Al.  A2,  A3,  A4,  A5 , 

FPO,  FPl,  FP2,  FP3,  FP5,  FP6 ) ) ; 

The  next  example  shows  the  use  of  renaming  with  an  imported  pro¬ 
cedure  (it  is  assumed  that  these  declarations  occur  in  a  declarative 
part  or  package  specification).  Note  that  the  renaming  causes  the  im¬ 
ported  ASSEMBLER  procedure  to  be  used  in  calls  to  both  -procedures 
CHANGE  and  EXCHANGE.  Also  note  that  because  no  external  desig¬ 
nator  is  specified,  the  builder  global  symbol  associated  with  the  external 
subprogram  is  EXCHANGE,  and  because  no  parameter  mechanisms 
are  specified,  the  compiler's  defaults  will  apply  in  calls  to  CHANGE  or 
EXCHANGE. 

precmdurm  CHANGE  (X,Y  :  INTEGER); 

proemdurm  EXCHANGE  (X,Y  ;  INTEGER)  rmnaamn  CHANGE; 

pragma  INTERFACE  (ASSEMBLER,  EXCHANGi); 

pragma  IMPORT_PROCEOURe  (INTERNAL  •>  EXCHANGE, 

PARAMETER_TYPES  •>  ( INTEGER, INTEGER)); 


->  SORT, 

->  ( LCNG_FLCAT) , 
->  LOHG_FLCAT, 

->  ( VALUE) FP5 )) , 
->  VALUE) FP4), 

->  -MTHSDSQRT", 


Exporting  Subprogram* 

XD  Ada  provides  two  pragmas  for  exporting  subprograms: 
EXPORT.FUNCTION  and  EXPORT.PROCEDURE,  Both  export  prag¬ 
mas  establish  an  external  name  for  a  subprogram  and  make  the  name 
available  to  the  XD  Ada  Builder  as  a  global  symbol,  so  that  the  subpro¬ 
gram  can  be  called  by  an  assembly  language  module. 

The  EXPORT.FUNCTION  and  EXPORT.PROCEDURE  pragmas  allow 
the  export  of  the  kind  of  subprograms  indicated. 
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The  pragmas  for  exporting  subprograms  have  the  following  form: 

pra^aa  E.XPCRT_F'JNCT!  :tJ  |  RT_?BO'EC'w’RE 

I  (  INTERNAL  •>  1  in'ernal_r.ame 

[,  (EXTERNAL  «>!  external_designator  1 

(,  ( FARAMETER_TVrES  ■>!  (  parameter_^ •  ! 

(,  (RESULT_TYPE  •>  |  I:ype_nar)t  |  --  FUNCTION  only 

(,  (MECHANISM  ->)  mechanism  | 

(,  ( RESULT_MECHANISM  ->J  mechanism_spec  )  --  FUNCTION  only 

I  ; 

parameter_typea 

null  T  tvpe_mark  {,  tvpe_marX> 
mechanism  i:- 

mecnaniam_spec  I  (  mechanism_spec  {,  mechanism_spec )  ) 
mechanism_spec  !:« 

mechanism_name  (  (  (REGISTER  ->  )  reqister_naine  )  ) 
mechaniam_name  i:- 

value"  I 

REFERENCE  j  BIT_REFERENCE  | 

DOPE_ VECTOR  j  BIT_OOPE_VECTOR 

reqisters  i:- 

Bull  I  reqlster_najiie  (,  rsqister_name  } 

parameter_typea  i:- 

Bull  I  type_marlt  {,  type_mark) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  j7ackage 
specificahon.  Otherwise,  the  parameter  types  must  be  specified. 

The  external  designator  denotes  an  XD  Ada  Builder  global  symbol 
that  is  associated  with  the  external  subprogram.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 
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The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine.  Mechanism  options  and  possible 
values  for  mechanism  names  and  class  names  are  described  in  Section 
13.9a.l.l. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 

The  result  mechanism  option  is  used  only  for  functions;  it  specifies 
the  parameter-passing  mechanism  for  passing  the  result  type,,  and 
optionally,  a  specific  register  used  to  pass  the  result. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  exporting 
subprograms  are  as  follows: 

•  An  exported  subprogram  must  be  a  library  unit  or  be  declared  in 
the  outermost  declarative  part  of  a  library  package.  Thus,  pragmas 
for  exporting  subprograms  are  allowed  only  in  the  following  cases: 

—  For  a  subprogram  specification  or  a  subprogram  body  that  is  a 
library  unit 

—  For  a  subprogram  specification  that  is  declared  in  the  outermost 
declarations  of  a  package  specification  or  a  package  body  that  is 
a  library  unit 

—  For  a  subprogram  body  that  is  declared  in  the  outermost  decla¬ 
rations  of  a  package  body  that  is  a  library  unit 

Consequently,  an  export  pragma  for  a  subprogram  body  is  allowed 
only  if  either  the  body  does  not  have  a  corresponding  specification, 
or  the  specification  and  body  occur  in  the  same  declarative  part. 

This  set  of  rules  implies  that  an  EXPORT_FUNC TION  or 
EXPORT.PROCEDUBE  pragma  cannot  be  given  for  a  generic  li¬ 
brary  subprogram,  nor  can  one  be  given  for  a  subprogram  declared 
in  a  generic  library  package.  However,  either  of  these  pragmas 
can  be  given  for  a  subprogram  resulting  from  the  instantiation  of 
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a  generic  subprogram,  provided  that  the  instantiation  otherwise 
satisfies  this  set  of  rules 

•  In  the  case  of  a  subprogram  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  subprogram  declaration  and  before 
any  subsequent  compilation  unit. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  with  a  renaming  declaration. 

•  Neither  of  these  pragmas  can  be  used  for  a  subprogram  that  is 
declared  by  a  generic  instantiation  of  a  built-in  library  subprogram 
(such  as  UNCHECKED.CONVERSION). 

Eximplta: 

The  following  example  shows  an  export  pragma  that  causes  the  Ada 
procedure  PROC  to  be  exported  for  use  in  an  assembly  language 
module.  The  name  PPOC  is  declared  as  an  XD  Ada  Builder  global 
symbol. 

preeadur*  PROC  (Y  :  INTEGER); 

prapM  EXPORT_PROCEDURE  (PROC);  -  ’ 

The  next  example  shows  an  Ada  function  being  called  from  an  assembly 
language  module: 

fuBCtiaa  MULTIPLY  (Y  !  ta  INTEGER)  ratura  INTEGER  la 

bafla 

ratura  Y  ♦  10; 

aad; 

pra«M  EXPORT_rUNCTION  (  INTERNAL  ->  MULTIPLY, 

PARAMETER_TYPES  ->  (INTEGER), 

RESULT_TYPE  ->  INTEGER  ); 

pragaa  CALL_SEQVENCS_FVNCTICN  I 

UNIT  •>  MULTIPLY, 

PARAMETER_TYPES  •>  (INTEGER), 

MECHANISM  •>  )VALUE(00)), 

RESULT  MECHANISM  ■>  VALUE ( 00 )) ; 


TITLE  *MC6B020  Calling  Ada* 
MODULE  *CALL_ADA* 

XDEE  CALL_ADA 
XREF  MULTIPLY 

DSEG 

A  BLKB  4  1  An  INTEGER 

PSEG 
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MCVE. L 

tl.A 

MOVE . L 

A,  DO 

JSR 

MULTIPLY. L 

MOVE.L 

DO,  A 

RTS 

END 

13. 9a. 2  Importing  and  Exporting  Objects 

XD  Ada  provides  two  pragmas  for  importing  and  exporting  objects: 
IMPORT.OBJECT  and  EXPORT.OBIECT.  The  IMPORT.OBJECT 
pragma  references  storage  declared  in  an  assembly  language  module. 
The  EXPORT.OBJECT  pragma  allows  an  assembly  language  module  to 
refer  to  the  storage  allocated  for  an  Ada  object. 

In  addition  to  the  rules  given  in  Section  13.9a,  the  rules  for  importing 
and  exporting  objects  are  as  follows: 

•  The  object  to  be  imported  or  exported  must  be  a  variable  declared 
by  an  object  declaration  at  the  outermost  level  of  a  library  package 
specification  or  body. 

•  The  subtype  indication  of  an  object  to  be  imported  or  exported  must 
denote  one  of  the  following; 

—  A  scalar  type  or  subtype. 

—  An  array  subtype  with  static  index  constraints  whose  component 
size  is  static. 

—  A  record  type  or  subtype  that  does  not  have  a  variant  part  and 
in  which  any  constraint  for  each  component  and  subcomponent 
is  static  (a  simple  record  type  or  subtype). 

•  Import  and  export  pragmas  are  not  allowed  for  objects  declared 
with  a  renaming  declaration. 

•  Import  and  export  pragmas  for  objects  are  not  allowed  in  a  generic 
unit. 
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Notes: 


13.9a.2.1 


Objects  of  private  or  limited  private  types  cannot  be  imported  or 
exported  outside  the  package  that  declares  the  (limited)  private  type. 
They  can  be  imported  or  exported  inside  the  body  of  the  package  where 
the  type  is  declared  (that  is  where  the  full  type  is  known). 

The  XD  Ada  pragmas  for  importing  or  exporting  objects  can  precede  or 
follow  a  pragma  VOLATILE  for  the  same  objects  (see  Section  9. 1 1). 

Address  clauses  are  not  allowed  in  combination  with  any  of  the  XD  Ada 
pragmas  for  importing  or  exporting  objects.  If  used  in  such  cases,  the 
pragma  involved  is  ignored  (see  Section  13.5). 


Importing  Objoct* 

The  XD  Ada  IMPORT_OBJECT  pragma  specifies  that  the  storage  allo¬ 
cated  for  the  object  (when  the  assembly  language  module  is  compiled) 
be  made  known  to  the  calling  Ada  program  by  an  externally-defined  XD 
Ada  Builder  global  symbol. 

Pragma  IMPORT.OBJECT  has  the  following  form: 

prafsa  IMPORT_OBJeCT 

(  internal_nanie  (,  externaX_desiqnator  )  ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Because  it  is  not  created  by  an  Ada  elaboration,  an  imported  object 
cannot  have  an  initial  value.  Specifically,  this  restriction  means  that  the 
object  to  be  imported: 

•  Cannot  be  a  constant  (have  an  explicit  initial  value). 

•  Cannot  be  an  access  type  ^'vhich  has  a  default  initial  value  of  null). 

•  Cannot  be  a  record  type  that  has  discriminants  (which  are  always 
initialized)  or  components  with  default  initial  expressions. 

•  Cannot  be  an  object  of  a  task  type. 
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Example: 

P!D:  INTEC;EB; 

prayaa  IMPCRT_':bjECT  (PIO,  TRO'-ESSSID- )  ; 

In  this  example,  the  variable  PID  refers  to  the  externally-defined  symbol 
PROCESSSID 

Alternatively,  this  example  can  be  written  in  named  notation  as  follows: 

PID  :  INTEGER; 

pragma  IMPORT_OBJECT  (INTERNAL  =>  PID, 

EXTERNAL  =■>  ' PRCCESSS I D"  )  : 


13.98.2.2  Exporting  Objects 

The  XD  Ada  pragma  EXPORT_OBJECT  specifies  that  the  storage  al¬ 
located  for  the  object  (when  the  Ada  program  is  compiled)  be  made 
known  to  assembly  language  modules  by  an  XD  Ada  Builder  global 
symbol. 

Pragma  EXPORT_OBJECT  has  the  following  form: 

pragma  EXPORT_OBJECT 

( internal_nam«  (,  external_de8iqnator ) ) 

The  internal  name  is  the  object  identifier.  The  external  designator 
denotes  an  XD  Ada  Builder  global  symbol  that  is  associated  with  the 
external  object.  If  no  external  designator  is  given,  the  internal  name  is 
used  as  the  global  symbol. 

Example: 

PID;  INTEGER; 

pragma  EXPORT_OBJECT  (PID,  -PROCESSSID" ) : 

Alternatively,  this  example  can  be  written  in  named  notation: 

PIDi  INTEGER: 

pragma  EXPOBT_OBJECT  (INTERNAL  ->  PID, 

EXTERNAL  ->  'PROCESSSID"): 
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13. 9a. 3  Importing  and  Exporting  Exceptions 

XD  Ada  provides  the  IMPORT.EXCEPTION  .ind  EXPORT. EXCEPTION 
pragmas  for  importing  and  exporting  exceptions.  The  pragma  IMPORT. 
EXCEPTION  allows  non-Ada  exceptions  to  be  used  in  Ada  programs; 
the  pragma  EXPORT.EXCEPTION  allows  Ada  exceptions  to  be  used  by 
foreign  units. 

The  rules  for  importing  and  exporting  exceptions  are  given  in  Section 
13.9a. 

Note: 

A  pragma  for  an  exception  that  is  declared  in  a  package  specification  is 
not  allowed  in  the  package  body. 


13. 9a. 3.1  Importing  Excaptiona 

The  XD  Ada  IMPORT.EXCEPTION  pragma  is  provided  for  compatibil¬ 
ity  with  VAX  Ada.  This  pragma  specifies  that  the  exception' associated 
with  an  exception  declaration  in  an  Ada  program  be  defined  externally 
in  non-Ada  code. 

In  XD  Ada  pragma  IMPORT.EXCEPTION  has  the  following  form; 

pragaa  IMPORT.EXCEPTION 

( Internal. name  (,  external. designator ) 

( ,  ( FORM  -> 1  ADA  1 ) ; 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception.  If  no  external  name  is 
given,  the  internal  name  is  used  as  the  global  symbol. 

For  compatibility  with  VAX  Ada,  the  form  option  indicates  that  an  Ada 
exception  is  being  imported.  If  omitted,  this  defaults  to  ADA. 

The  external  designator  refers  to  an  address  that  identifies  the  excep¬ 
tion. 

The  VAX  Ada  version  of  this  pragma  supports  an  alternative  form 
(VMS),  and  a  code  option  in  addition  to  the  XD  Ada  arguments.  If 
either  of  these  unsupported  arguments  is  specified,  the  compiler  ignores 
the  pragma  and  issues  a  warning  message. 


Importing  Exceptions  13. 9a. 3.1 
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13.98.3.2  Exporting  Exceptions 

The  XD  Ada  EXPORT_EXCEPTION  pragma  allows  Ada  exceptions  to 
be  visible  outside  the  XD  Ada  program,  so  that  they  can  be  raised  and 
handled  by  programs  written  in  XD  Ada  MC68020  assembly  language. 
This  pragma  establishes  an  external  name  for  an  Ada  exception  and 
makes  the  name  available  to  the  XD  Ada  Builder  as  a  global  symbol. 
Refer  to  the  XD  Ada  MC68020  Run-Time  Reference  Manual  for  further 
information  on  exporting  exceptions. 

Pragma  EXPORT_EXCEPTION  has  the  following  form: 

pragaa  EXPORT_EXCEPTIOM 

( internal_name  (,  external_desiqnator ) 

( ,  ( FORM  “> I  ADA  ) ) ; 

The  internal  name  must  be  an  Ada  identifier  that  denotes  a  declared 
exception.  The  external  designator  denotes  an  XD  Ada  Builder  global 
symbol  to  be  used  to  refer  to  the  exception. 

The  form  option  specifies  that  an  Ada  exception  is  being  exported. 

Example: 

UNDERFLOW  !  aacaptioa 

prapaa  EXPORT_EXCEPTION  (UNDERFLOW,  MTH_UNDERFLOW,  ADA); 

In  this  example,  an  Ada  exception  is  exported  as  a  global  symbol. 
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Exporting  Exceptions 


13.10  Unchecked  Programming 


13.10.1  Unchecked  Storage  Deallocation 

The  following  information  supplements  the  Notes  section; 

Because  UNCHECKED_DEALLOCATION  is  a  predefined  generic  pro¬ 
cedure,  XD  Ada  does  not  allow  the  use  of  the  lMPORT_PROCEDURE 
pragma  to  substitute  an  alternative  procedure  body. 


13.10.2  Unchecked  Type  Conversions 

The  following  information  supplements  paragraph  2: 

XD  Ada  supports  the  generic  function  UNCHECKED_CONVERSION 
with  the  following  restrictions  on  the  class  of  types  involved: 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  array  type. 

•  The  actual  subtype  corresponding  to  the  formal  type  TARGET  must 
not  be  an  unconstrained  type  with  discriminants. 

Further,  when  the  target  type  is  a  type  with  discriminants,  the  value 
resulting  from  a  call  of  the  conversion  function  resulting  from  an  instan¬ 
tiation  of  UNCHECKED.CONVERSION  is  checked  to  ensure  that  the 
discriminants  satisfy  the  constraints  of  the  actual  subtype. 

The  effect  with  XD  Ada  is  as  if  the  source  value  is  copied  one  byte 
in  ascending  order  of  address,  into  the  destination,  also  in  ascending 
order  of  address.  If  the  destination  has  fewer  bytes  than  the  source 
value,  the  high  order  bytes  of  the  source  value  are  ignored  (truncated). 
If  the  source  value  has  fewer  bytes  than  the  destination,  the  high  order 
bytes  of  the  destination  are  set  to  zero. 


13.10.2 


Unchecked  Type  Conversions 
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Chapter  13 

Representation  Clauses  and 
Implementation-Dependent 

Features 


This  chapter  describes  XD  Ada  MC68020  Version  1.2  internipt  handling. 
In  particular,  it  describes  the  handling  of  direct  interrupt  entries,  and 
use  of  pragma  DIRECT.INTERRUPT.ENTRY. 


13.5.1  Interrupts 

The  following  information  supplements  all  of  this  section: 

Unlike  VAX  Ada,  XD  Ada  supports  interrupts.  The  address  in  the  use 
clause  is  the  address  of  the  interrupt.  The  address  is  interpreted  as  an 
offset  in  bytes  from  the  vector  base  register.  For  details  of  MC68020 
exception  vector  assignments,  see  Table  6-2  of  the  MC68020  32-Bit 
Microprocessor  User's  Manual.  Note  that  when  assigning  vectors,  the 
offset  is  a  multiple  of  four  of  the  vector  number.  In  this  way,  vector 
number  64  (decimal)  would  have  the  hexadecimal  offset  100. 

In  addition  to  support  for  normal  Ada  interrupt  entries,  XD  Ada 
provides  the  additional  pragmas  LEVEL  and  DIRECT_INTERRUPT_ 
ENTRY.  Pragma  LEVEL  is  given  for  a  task  type,  or  single  task  of  anony¬ 
mous  type,  and  gives  the  level  for  its  interrupts.  Pragma  DIRECT, 
INTERRUIT.ENTRY  is  used  to  connect  an  interrupt  entry  directly  to  the 
required  interrupt  vector,  and  is  described  below. 
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There  are  two  ways  an  interrupt  entry  can  be  handled,  according  to 
whether  or  not  the  task  has  a  pragma  LEVEL.  The  XD  Ada  X1C68020 
Run-Time  Reference  Manual  gives  examples  of  interrupt  handlers. 

Tasks  with  interrupt  entries  but  no  pragma  LEVEL  run  at  interrupt  level 
0  only  while  accepting  an  interrupt  in  a  rendezvous.  Other  interrupts  of 
the  same  level  or  lower  levels  are  inhibited  while  in  the  handler.  It  is 
however,  possible  to  lose  interrupts  with  this  method. 

Tasks  with  interrupt  entries  and  a  pragma  LEVEL  always  run  at  interrupt 
level,  whether  inside  or  outside  a  rendezvous.  This  enables  the  user  to 
avoid  losing  interrupts. 

An  interrupt  entry  to  a  task  with  the  pragma  LEVEL  behaves  like  an 
ordinary  entry  call.  An  interrupt  entry  to  a  task  with  no  pragma  LEVEL 
behaves  like  a  conditional  entiy  call.  If  there  is  an  accept  statement 
waiting  for  the  interrupt,  the  body  of  the  accept  statement  is  executed 
immediately.  When  the  body  is  complete,  the  task  is  inserted  in  the 
ready  queue  and  the  interrupt  completed  by  a  return-from-interrupt 
instruction.  The  accept  statement  can  call  subprograms  and  make  entry 
calls,  but  must  not  suspend  the  task  before  the  interrupt  is  dismissed, 
otherwise  the  program  repeatedly  services  the  interrupt  unsuccessfully. 

Writing  interrupt  handlers  in  XD  Ada  requires  detailed  knowledge  of 
the  behavior  of  the  target  computer's  interrupt  system.  It  is  not  possible 
simply  to  place  a  use  clause  on  an  entry  to  achieve  the  desired  effect. 

Normal  Ada  interrupt  entries  cause  a  tasking  reschedule  each  time  an 
interrupt  occurs.  This  inevitably  incurs  a  performance  overhead,  and 
may  mean  that  interrupts  are  not  serviced  quickly  enough.  In  order  to 
avoid  this  problem,  XD  Ada  supplies  pragma  DIRECTJNTERRUPT. 
ENTRY,  which  causes  the  interrupt  entry  to  be  connected  directly  to 
the  required  interrupt  vector.  This  run  time  efficiency  greatly  improves 
response  times.  The  form  of  this  pragma  is  as  follows. 

prafM  DIRBCT^INTERROPT_ENTRY(interrupt_entry)  j 

Pragma  DIRECT.INTERRUPT.ENTRY  may  be  used  where  the  pro¬ 
gram  adheres  to  one  of  two  supported  code  models.  In  fact,  most 
^plications  will  naturally  adhere  to  one  or  other  of  the  models,  so  the 
practical  restrictions  from  this  requirement  are  minimal.  The  use  of 
pragma  DIRECT_1NTERRUPT_ENTRY  must  meet  certain  semantic  con¬ 
ditions.  These,  along  with  the  checks  carried  out  by  the  compiler  and 
run-time  system,  are  described  in  full  in  the  XD  Ada  MC68020  Run-Time 
Reference  Manual  part  of  this  manual. 
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Note  that  it  is  essential  that  the  lowest  level  direct  interrupt  (or  interrupt 
procedure)  is  always  higher  than  the  highest  level  normal  interrupt,  in 
order  that  the  direct  interrupt  context  is  not  left  as  a  result  of  inlerruptive 
preemption. 

The  models  and  the  related  conditions  are  described  in  full,  and  exam¬ 
ples  of  the  models  in  use  are  given,  in  the  XD  Ada  MC68020  Run  Time 
Reference  Manual  part  of  this  manual. 

Interrupt  procedures  and  Package  INTERRUPT.SUPPORT  are  also 
described  in  the  XD  Ada  MC68020  Run-Time  Reference  Manual  part  of  this 
manual. 


13.5.1  Interrupts 


13-3 


Annex  B 


Predefined  Language  Pragmas 


This  chapter  supplies  details  of  three  pragmas  introduced  by  XD  Ada 
MC68020  Version  1.2,  pragma  DIRECT.INTERRUPT. ENTRY,  pragma 
IDENT  and  pragma  TIME_SLICE.  XD  Ada  pragmas  in  addition  to  those 
defined  in  Annex  B  of  the  Reference  Manual  for  the  AdaProgramming 
Language  (CALL.SEQUENCE.FUNCTION,  CALL  SEQUENCE 
PROCEDURE,  LEVEL.  UNK.OPTION  and  TITLE)  are  described  in 
the  XD  Ada  MC68020  Supplement  to  the  Ada  Language  Reference  Manual  for 
Version  1.0. 

Ocfinitlon* 

IDENT 

Takes  a  string  literal  of  ST  or  fewer  characters  as  the  single  argument. 
The  pragma  iDENT  has  the  following  form: 

prcffM  IDBNT  (■trinq.literal); 

This  pragma  is  allowed  only  in  the  outermost  declarative  part  of  a  • 
compilation  unit.  The  given  string  is  used  to  identify  the  object  module 
associated  with  the  compilation  unit  in  which  the  pragma  IDENT  occurs. 

Summary 

Pragma  Meaning 

DIRECT_INTERRUPT_ENTRY  Takes  the  simple  name  of  an  interrupt 

entry,  which  must  have  no  parameters, 
as  the  single  argument.  This  pragma 
signals  to  the  compiler  that  the  interrupt 
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In  addition  to  the  standard  predefined  pragmas,  described  in  Annex  B 
of  the  Reference  Manual  for  the  Ada  Programming  Language.  XD  Ada  sup¬ 
ports  pragmas  CALL_SEQUENCE_FUNCT10N,  CALL.SEQUENCE. 
PROCEDURE,  LINK_0PT10N.  and  TITLE,  which  are  defined  here. 
This  annex  also  summarizes  the  definitions  given  elsewhere  of  the 
remaining  implementation-defined  pragmas. 

0«flnition« 

CALL  SEQUENCE  FUNCTION 
CALL.SEQUENCE.PROCEDURE 

The  pragma  CALL_SEQUENCE_PROCEDURE  is  used  for  describing 
machine  code  insertions  or  exported  subprograms.  It  specifies  how 
parameters  are  mapped  onto  registers,  and  which  registers  must  be 
preserved,  for  machine  code  insertions  (see  Section  13.8).  The  pragma 
CALL_SEQUENCE_FUNCTION  is  also  provided.  These  pragmas  have 
the  form: 

prayM  CALL_SEQUENCB_FUNCTION 

((  (UNIT  ■>)  internal_name 
(,  ( BESUI,T_TYPE  ->)  type_marX  ) 

(,  (  PARAMETEB_TYPES  ->)  7  paraiiieter_types  )  ) 

(,  (MECHANISM  •>]  mechanism  ) 

[,  (RESULT_MECHANISM  -> )  mechanism_spec  ) 

(,  ( PRESBRVBO_REGISTBRS  ->  (  (  registers  |  j 
)  ! 

prmfmm  CALL_SE(JOENCE_PROCEDURE 

([  (UNIT  ->)  internal_nai«e 
(,  ( PARAMETER_TYPES  -> )  (  parBmeter_types  )  ) 

(,  (MECHANISM  •>)  mechanism  ) 

(,  [PRESERVED_REGISTERS  ->  ]  (  registers  I  | 

); 
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paranieter_tvpps  = 

Dull  I  type_:ii3:k  {,  '  vpe_-arV  > 

mechanism 

mechanism_3pec  |  (  mprh3r.ism_r,pec  (,  -pch.imr^n  rppi-v  ) 

mechanism_spec 

mechanism_name  j  (  (PEjISTER  ”>  )  rp'^is.er  name  )  ] 

mechanism_name 

value”  I 

REFERENCE  j  BIT_REFERENCE  | 

DOPE_VECTOR  j  BIt”d‘:'PE_VECTOR 

registers  <:• 

null  I  register_naiiie  (,  reqister_name  ) 

Functions  must  be  identified  by  their  internal  names  and  parameter 
and  result  types.  The  parameter  and  result  types  can  be  omitted  only  if 
there  is  exactly  one  function  of  that  name  in  the  same  declarative  part  or 
package  specification.  Otherwise,  both  the  parameter  and  result  types 
must  be  specified. 

Procedures  must  be  identified  by  their  internal  names  and  parameter 
types.  The  parameter  types  can  be  omitted  only  if  there  is  exactly 
one  procedure  of  that  name  in  the  same  declarative  part  or  package 
specification.  Otherwise,  the  parameter  types  must  be  specified. 

The  parameter  types  option  specifies  a  series  of  one  or  more  type 
marks  (type  or  subtype  names),  not  parameter  names.  Each  type  mark 
is  positionally  associated  with  a  formal  parameter  in  the  subprogram's 
declaration.  The  absence  of  parameters  must  be  indicated  by  the 
reserved  word  null. 

The  result  type  option  is  used  only  for  functions;  it  specifies  the  type  or 
subtype  of  the  function  result. 

The  mechanism  option  specifies  how  the  imported  subprogram  expects 
its  parameters  to  be  passed  (for  example,  by  value,  by  reference  or 
by  descriptor).  The  calling  program  (namely  the  XD  Ada  program) 
is  responsible  for  ensuring  that  parameters  are  passed  in  the  form 
required  by  the  external  routine. 

If  the  first  form  of  the  mechanism  option  is  given  (a  single  mechanism 
name  without  parentheses),  all  parameters  are  passed  using  that  mech¬ 
anism.  If  the  second  form  is  given  (a  series  of  mechanism  names  in 
parentheses  and  separated  by  commas),  each  mechanism  name  de¬ 
termines  how  the  parameter  in  the  same  position  in  the  subprogram 
specification  will  be  passed.  With  the  second  form,  each  parameter 
name  must  have  an  associated  mechanism  name. 
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entry  is  to  be  directly  connected  to  the 
hardware  interrupt  (see  Section  13.5.1). 

Takes  a  static  expression  of  the  prede¬ 
fined  fixed  point  type  DURATION  (in 
Package  STANDARD)  as  the  single  ar¬ 
gument.  This  pragma  is  only  allowed 
in  the  outermost  declarative  part  of  a 
library  subprogram,  and  at  most  one 
such  pragma  is  allowed  in  a  library  sub¬ 
program.  It  has  an  effect  only  when 
the  subprogram  to  which  it  applies  is 
used  as  a  main  program.  This  pragma 
specifies  the  nominal  amount  of  elapsed 
time  permitted  for  the  execution  of  a  task 
when  other  tasks  of  the  same  priority  are 
also  eligible  for  execution.  A  positive, 
nonzero  value  of  the  static  expression 
enables  scheduling  for  all  tasks  in  the 
subprogram;  a  negative  or  zero  value 
disables  it  (see  Section  9.8a). 


The  result  mechanism  option  is  used  only  for  functions;  it  specifies  the 
parameter  passing  mechanism  for  passing  the  result  type. 

Mechanism  names  are  described  in  Section  13.9a.  11. 

The  preserved  registers  option  gives  a  list  of  hardware  registers  which 
are  not  altered  by  the  procedure  or  function.  If  this  option  is  omitted  it 
implies  that  no  registers  are  preserved;  in  this  case  the  effect  is  one  of 
the  following: 

•  If  the  body  of  the  subprogram  is  written  in  Ada,  the  compiler 
calculates  which  registers  are  preserved 

•  If  the  body  of  the  subprogram  is  a  machine  code  insertion,  the 
pragma  has  the  same  effect  as  pragma  IMPORT_PROCEDURE 


LINK.OPTION 

This  pragma  is  used  to  associate  lirUc  option  file  names  with  a  program. 
Link  option  files  are  used  to  specify  the  target  and  mapping  definitions 
to  be  used  when  building  the  program.  In  this  way,  they  do  not  have 
to  be  explicitly  defined  on  the  XDACS  LINK  command  line%  The 
appropriate  external  target  and  mapping  definitions  (in  the  form  of  liitk 
option  files)  are  entered  into  the  program  library  by  use  of  the  XDACS 
command  COPY  LINK_0PT10N/F0REIGN,  as  described  in  Dervlopirtg 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020.  If  a  suitable  link 
option  file  exists  in  another  program  library,  it  can  be  copied  to  the 
current  program  library  with  the  XDACS  command  COPY  LINK_ 
OPTION.  The  advantage  of  using  link  option  files  is  that  the  program 
oefinition  is  separate  from  the  program  itself,  and  so  can  be  altered 
without  making  the  last  compile  obsolete.  The  LINK.OPTION  pragma 
therefore  removes  the  need  to  recompile  the  whole  program.  More 
detail  on  this  topic  can  be  found  in  Sections  7.9  and  8. 10  of  Deivloping 
XD  Ada  Programs  on  VMS  Systems  for  the  MC68020. 

Pragma  LINK.OPTION  has  the  form: 

pcmtmm  LINK_OPTION( ( 

I  (TARGiT-> 1  link-option-file-name) 

[ ,  [MAPPING->llink-option-f ile-name) 

1); 

This  pragma  is  only  allowed  in  the  outermost  declarative  part  of  a 
subprogram  that  is  a  library  unit;  at  most  one  such  pragma  is  allowed 
in  a  subprogram.  If  it  occurs  in  a  subprogram  other  than  the  main 
program,  this  pragma  has  no  effect  (see  Sections  9.8  and  9.9  (LRM)). 
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TITLE 


Takes  a  title  or  a  subtitle  string,  or  both,  in  either  order,  as  arguments. 

Pragma  TITLE  has  the  form: 

pragaa  TITLE  ( 1 1 1 1  inq-opt i 
(  ,  1 1  r 1  inq-opt ion  I ) ; 

titling-option  :« 

(TITLE  ->)  St r inq_l i ter 
I  (SUBTITLE  •>)  strinq_literal 

This  pragma  is  alloived  anywhere  a  pragma  is  allowed;  the  given  strings 

supersede  the  default  title  or  subtitle  portions  of  a  compilation  listing. 

Summary 

Pragma  Meaning 

EXPORT, EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an 
external  designator  (the  name  of  an 
XD  Ada  Builder  global  symbol),  and 
a  form  (ADA)  as  arguments.  This 
pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  an  exception  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  The 
pragma  permits  an  Ada  exception  to 
be  handled  by  programs  written  in  XD 
Ada  MC68020  assembly  language  (see 
Section  13. 9a. 3. 2). 

EXPORT_FUNCTION  Takes  an  internal  name  denoting  a 

function,  and  optionally  takes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  parameter 
types,  and  result  type  as  arguments. 

This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item,  and  must  apply 
to  a  function  declared  by  an  earlier 
declarative  item  of  the  same  declara¬ 
tive  part  or  package  specification.  In 
the  case  of  a  function  declared  as  a 
compilation  unit,  the  pragma  is  only 
allowed  after  the  function  declaration 
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EXPORT_OBJECT 


EXPORT.  PROCEDURE 


.ind  before  any  subsequent  compilation 
ui.it.  This  pragma  is  not  allowed  for  a 
function  declared  with  a  renaming  dec¬ 
laration.  and  is  not  allowed  for  a  generic 
function  (it  can  be  given  for  a  generic 
instantiation).  This  pragma  permits  an 
Ada  function  to  be  called  from  a  pro¬ 
gram  written  in  assembly  language  (see 
Section  13. 9a.  1.2). 

Takes  an  internal  name  denoting  an 
object,  and  optionally  tcikes  an  exter¬ 
nal  designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  size  des¬ 
ignator  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item  at  the  outermost  level  of  a  library 
package  specification  or  body,  and  must 
apply  to  a  variable  declared  by  an  earlier 
declarative  item  of  the  same  package 
specification  or  body;  the  variable  must 
be  of  a  type  or  subtype  that  -has  a  con¬ 
stant  size  at  compile  time.  This  pragma 
is  not  allowed  for  objects  declared  with  a 
renaming  declaration,  and  is  not  allowed 
in  a  generic  unit.  This  pragma  permits 
an  Ada  object  to  be  referred  to  by  a 
routine  written  in  assembly  language  (see 
Section  13. 9a. 2. 2). 

Takes  an  internal  name  denoting  a  pro¬ 
cedure,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  and  parameter 
types  as  arguments.  This  pragma  is  only 
allowed  at  the  place  of  a  declarative  item, 
and  must  apply  to  a  procedure  declared 
by  an  earlier  declarative  item  of  the  same 
declarative  part  or  package  specification. 
In  the  case  of  a  procedure  declared  as 
a  compilation  unit,  the  pragma  is  only 
allowed  after  the  procedure  declaration 
and  before  any  subsequent  cc  mpilation 
unit.  This  pragma  is  not  allowed  for 
a  procedure  declared  with  a  renaming 
declaration,  and  is  not  allowed  for  a 
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generic  procedure  (if  may  be  given  for 
a  generic  instantiation)  This  pragma 
permits  an  Ada  routine  to  be  called  from 
a  program  written  in  assembly  language 
(see  Section  13.9a.  12). 

IMPORT, EXCEPTION  Takes  an  internal  name  denoting  an 

exception,  and  optionally  takes  an  ex¬ 
ternal  designator  {the  name  of  an  XD 
Ada  Builder  global  symbol),  and  a  form 
(ADA)  as  arguments.  This  pragma  is 
only  allowed  at  the  place  of  a  declarative 
item,  and  must  apply  to  an  exception 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  The  pragma  is  included  for 
compatibility  with  VAX  Ada  (see  Section 
13.9a. 3.1). 

lMPORT_FUNCnON  Takes  an  internal  name  denoting  a  func¬ 

tion,  and  optionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  parameter  types, 
and  result  type  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declar¬ 
ative  item,  and  must  apply  to  a  function 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  package 
specification.  In  the  case  of  a  func¬ 
tion  declared  as  a  compilation  unit,  the 
pragma  is  only  allowed  after  the  function 
declaration  and  before  any  subsequent 
compilation  unit.  This  pragma  is  allowed 
for  a  function  declared  with  a  renaming 
declaration;  it  is  not  allowed  for  a  generic 
function  or  a  generic  function  instantia¬ 
tion.  This  pragma  permits  an  assembly 
language  routine  to  be  used  as  an  Ada 
function  (see  Section  13. 9a. 1.1). 
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IMPORT.OBJECT 


IMPORT.PROCEDURE 


Takec  an  internal  name  denoting  an 
object,  and  t'ptionally  takes  an  external 
designator  (the  name  of  an  XD  Ada 
Builder  global  symbol),  as  arguments. 
This  pragma  is  only  allowed  at  the  place 
of  a  declarative  item  at  the  outermost 
level  of  a  library  package  specification 
or  body,  and  must  apply  to  a  variable 
declared  by  an  earlier  declarative  item  of 
the  same  package  specification  or  body; 
the  variable  must  be  of  a  type  or  subtype 
that  has  a  constant  size  at  compile  time. 
This  pragma  is  not  allowed  for  objects 
declared  with  a  renaming  declaration, 
and  is  not  allowed  in  a  generic  unit.  This 
pragma  permits  storage  declared  in  an 
assembly  language  routine  to  be  referred 
to  by  an  Ada  program  (see  Section 
13.9a,2.1). 

Takes  an  internal  name  denoting  a 
procedure,  and  optionally  lakes  an  ex¬ 
ternal  designator  (the  name  of  an  XD 
Ada  Builder  global  symbol),  and  pa¬ 
rameter  types  as  arguments.  Pragma 
INTERFACE  must  be  used  with  this 
pragma  (see  Section  13.9).  This  pragma 
is  only  allowed  at  the  place  of  a  declara¬ 
tive  item,  and  must  apply  to  a  procedure 
declared  by  an  earlier  declarative  item 
of  the  same  declarative  part  or  pack¬ 
age  specification.  In  the  case  of  a 
procedure  declared  as  a  compilation 
unit,  the  pragma  is  only  allowed  after 
the  procedure  declaration  and  before 
any  subsequent  compilation  unit.  This 
pragma  is  allowed  for  a  procedure  de¬ 
clared  with  a  renaming  declaration;  it  is 
not  allowed  for  a  generic  procedure  or 
a  generic  procedure  instantiation.  This 
pragma  permits  an  assembly  language 
routine  to  be  used  as  an  Ada  procedure 
(see  Section  13. 9a.  1.1). 
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INTERFACE 

LEVEL 

STORAGE.UNIT 

SUPPRESS.ALL 

VOLATILE 


In  XD  Adii,  pragma  INTERFACE  is 
required  in  con\binalion  uith  pragmas 
IMPORT.FUNCTION  and  IMPORT. 
PROCEDURE  (see  Section  13  9a.l) 

This  pragma  identifies  a  task  or  task  type 
as  running  at  interrupt  level.  Pragma 
LEVEL  has  one  argument  specifying 
the  level  for  its  interrupts  (see  Section 
13.5.1). 

In  XD  Ada,  the  only  argument  allowed 
for  this  pragma  is  8. 

This  pragma  has  no  argument  and  is 
only  allowed  following  a  compilation 
unit.  This  pragma  specifies  that  all  run¬ 
time  checks  in  the  unit  are  suppressed 
(see  Section  11.7). 

Takes  the  simple  name  of  a  variable 
as  the  single  argument.  This  pragma 
is  only  allowed  for  a  variable  declared 
by  an  object  declaration.  The  variable 
declaration  and  the  pragma  must  both 
occur  (in  this  order)  immediately  within 
the  same  declarative  part  or  package 
specification.  The  pragma  must  appear 
before  any  occurrence  of  the  name  of 
the  variable  other  than  in  an  address 
clause  or  in  one  of  the  XD  Ada  pragmas 
IMPORT.OBJECT  or  EXPORT.OBJECT. 
The  variable  cannot  be  declared  by  a 
renaming  declaration.  The  VOLATILE 
pragma  specifies  that  the  variable  may  be 
modified  asynchronously.  This  pragma 
instructs  the  compiler  to  obtain  the  value 
of  a  variable  from  memory  each  time  it 
is  used  (see  Section  9.11). 
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